The patch titled cpusets: initialize spread rotor lazily has been added to the -mm tree. Its filename is cpusets-randomize-node-rotor-used-in-cpuset_mem_spread_node-cpusets-initialize-spread-rotor-lazily.patch Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find out what to do about this The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ ------------------------------------------------------ Subject: cpusets: initialize spread rotor lazily From: Michal Hocko <mhocko@xxxxxxx> Kosaki Motohiro raised a concern that copy_process is hot path and we do not want to initialize cpuset_{mem,slab}_spread_rotor if they are not used most of the time. I think that we should rather intialize it lazily when rotors are used for the first time. This will also catch the case when we set up spread mem/slab later. Also do not use -1 for unitialized nodes and rather use NUMA_NO_NODE instead. Signed-off-by: Michal Hocko <mhocko@xxxxxxx> Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx> Cc: Jack Steiner <steiner@xxxxxxx> Cc: Lee Schermerhorn <lee.schermerhorn@xxxxxx> Cc: Christoph Lameter <cl@xxxxxxxxxxxxxxxxxxxx> Cc: Pekka Enberg <penberg@xxxxxxxxxxxxxx> Cc: Paul Menage <menage@xxxxxxxxxx> Cc: Jack Steiner <steiner@xxxxxxx> Cc: Robin Holt <holt@xxxxxxx> Cc: David Rientjes <rientjes@xxxxxxxxxx> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> --- kernel/cpuset.c | 8 ++++++++ kernel/fork.c | 4 ++-- 2 files changed, 10 insertions(+), 2 deletions(-) diff -puN kernel/cpuset.c~cpusets-randomize-node-rotor-used-in-cpuset_mem_spread_node-cpusets-initialize-spread-rotor-lazily kernel/cpuset.c --- a/kernel/cpuset.c~cpusets-randomize-node-rotor-used-in-cpuset_mem_spread_node-cpusets-initialize-spread-rotor-lazily +++ a/kernel/cpuset.c @@ -2460,11 +2460,19 @@ static int cpuset_spread_node(int *rotor int cpuset_mem_spread_node(void) { + if (current->cpuset_mem_spread_rotor == NUMA_NO_NODE) + current->cpuset_mem_spread_rotor = + node_random(¤t->mems_allowed); + return cpuset_spread_node(¤t->cpuset_mem_spread_rotor); } int cpuset_slab_spread_node(void) { + if (current->cpuset_slab_spread_rotor == NUMA_NO_NODE) + current->cpuset_slab_spread_rotor + = node_random(¤t->mems_allowed); + return cpuset_spread_node(¤t->cpuset_slab_spread_rotor); } diff -puN kernel/fork.c~cpusets-randomize-node-rotor-used-in-cpuset_mem_spread_node-cpusets-initialize-spread-rotor-lazily kernel/fork.c --- a/kernel/fork.c~cpusets-randomize-node-rotor-used-in-cpuset_mem_spread_node-cpusets-initialize-spread-rotor-lazily +++ a/kernel/fork.c @@ -1126,8 +1126,8 @@ static struct task_struct *copy_process( mpol_fix_fork_child_flag(p); #endif #ifdef CONFIG_CPUSETS - p->cpuset_mem_spread_rotor = node_random(&p->mems_allowed); - p->cpuset_slab_spread_rotor = node_random(&p->mems_allowed); + p->cpuset_mem_spread_rotor = NUMA_NO_NODE; + p->cpuset_slab_spread_rotor = NUMA_NO_NODE; #endif #ifdef CONFIG_TRACE_IRQFLAGS p->irq_events = 0; _ Patches currently in -mm which might be from mhocko@xxxxxxx are memsw-remove-noswapaccount-kernel-parameter.patch memcg-remove-pointless-next_mz-nullification-in-mem_cgroup_soft_limit_reclaim.patch memcg-mark-init_section_page_cgroup-properly.patch memcg-fix-off-by-one-when-calculating-swap-cgroup-map-length.patch memcg-move-page-freeing-code-out-of-lock.patch maintainers-add-mm-page_cgroupc-into-memcg-subsystem.patch cpusets-randomize-node-rotor-used-in-cpuset_mem_spread_node.patch cpusets-randomize-node-rotor-used-in-cpuset_mem_spread_node-cpusets-initialize-spread-rotor-lazily.patch cpusets-randomize-node-rotor-used-in-cpuset_mem_spread_node-cpusets-initialize-spread-rotor-lazily-fix.patch -- To unsubscribe from this list: send the line "unsubscribe mm-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html