diff options
author | Kirill Tkhai <[email protected]> | 2014-11-11 12:46:29 +0300 |
---|---|---|
committer | Ingo Molnar <[email protected]> | 2014-11-16 10:59:01 +0100 |
commit | d8b163c4c657478ef33c082cff78d03a4ca07bb2 (patch) | |
tree | 9653413e705b55c48c23bb57bf6c21bdf774a40a /tools/perf/scripts/python/bin/export-to-postgresql-report | |
parent | c1a2b5f6293caa14804adca1840eeea1e8f6b322 (diff) |
sched/numa: Init numa balancing fields of init_task
We do not initialize init_task.numa_preferred_nid,
but this value is inherited by userspace "init"
process:
rest_init()->kernel_thread(kernel_init)->do_fork(CLONE_VM);
__sched_fork()
{
if (clone_flags & CLONE_VM)
p->numa_preferred_nid = current->numa_preferred_nid;
else
p->numa_preferred_nid = -1;
}
kernel_init() becomes userspace "init" process.
So, we propagate garbage nid to userspace, and it may be used
during numa balancing.
Currently, we do not have reports about this brings a problem,
but it seem we should set it for sure.
Even if init_task.numa_preferred_nid is zero, we may meet a weird
configuration without nid#0. On sparc64, where processors are
numbered physically, I saw a machine without cpu#1, while cpu#2
existed. Possible, something similar may be with numa nodes.
So, let's initialize it and be sure we're safe.
Signed-off-by: Kirill Tkhai <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Eric Paris <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Paul E. McKenney <[email protected]>
Cc: Sergey Dyasly <[email protected]>
Link: http://lkml.kernel.org/r/1415699189.15631.6.camel@tkhai
Signed-off-by: Ingo Molnar <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/bin/export-to-postgresql-report')
0 files changed, 0 insertions, 0 deletions