aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin/export-to-postgresql-report
diff options
context:
space:
mode:
authorKirill Tkhai <[email protected]>2014-11-11 12:46:29 +0300
committerIngo Molnar <[email protected]>2014-11-16 10:59:01 +0100
commitd8b163c4c657478ef33c082cff78d03a4ca07bb2 (patch)
tree9653413e705b55c48c23bb57bf6c21bdf774a40a /tools/perf/scripts/python/bin/export-to-postgresql-report
parentc1a2b5f6293caa14804adca1840eeea1e8f6b322 (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