diff for duplicates of <1310719055.2586.285.camel@twins> diff --git a/a/1.txt b/N1/1.txt index 4768fa0..c863ddd 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,21 +1,21 @@ On Fri, 2011-07-15 at 10:45 +1000, Anton Blanchard wrote: > Hi, ->=20 +> > > Urgh.. so those spans are generated by sched_domain_node_span(), and > > it looks like that simply picks the 15 nearest nodes to the one we've > > got without consideration for overlap with previously generated spans. ->=20 +> > I do wonder if we need this extra level at all on ppc64. From memory > SGI added it for their massive setups, but our largest setup is 32 nodes > and breaking that down into 16 node chunks seems overkill. ->=20 +> > I just realised we were setting NEWIDLE on our node definition and that > was causing large amounts of rebalance work even with -> SD_NODES_PER_DOMAIN=3D16. ->=20 +> SD_NODES_PER_DOMAIN=16. +> > After removing it and bumping SD_NODES_PER_DOMAIN to 32, things look > pretty good. ->=20 +> > Perhaps we should allow an arch to override SD_NODES_PER_DOMAIN so this > extra level is only used by SGI boxes. @@ -40,8 +40,7 @@ diff --git a/kernel/sched.c b/kernel/sched.c index 8fb4245..877b9f1 100644 --- a/kernel/sched.c +++ b/kernel/sched.c -@@ -7203,7 +7203,7 @@ static struct sched_domain_topology_level default_top= -ology[] =3D { +@@ -7203,7 +7203,7 @@ static struct sched_domain_topology_level default_topology[] = { #endif { sd_init_CPU, cpu_cpu_mask, }, #ifdef CONFIG_NUMA diff --git a/a/content_digest b/N1/content_digest index a88fcb7..33399de 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -9,30 +9,31 @@ "Date\0Fri, 15 Jul 2011 10:37:35 +0200\0" "To\0Anton Blanchard <anton@samba.org>\0" "Cc\0mahesh@linux.vnet.ibm.com" - linuxppc-dev@lists.ozlabs.org linux-kernel@vger.kernel.org + linuxppc-dev@lists.ozlabs.org mingo@elte.hu + benh@kernel.crashing.org " torvalds@linux-foundation.org\0" "\00:1\0" "b\0" "On Fri, 2011-07-15 at 10:45 +1000, Anton Blanchard wrote:\n" "> Hi,\n" - ">=20\n" + "> \n" "> > Urgh.. so those spans are generated by sched_domain_node_span(), and\n" "> > it looks like that simply picks the 15 nearest nodes to the one we've\n" "> > got without consideration for overlap with previously generated spans.\n" - ">=20\n" + "> \n" "> I do wonder if we need this extra level at all on ppc64. From memory\n" "> SGI added it for their massive setups, but our largest setup is 32 nodes\n" "> and breaking that down into 16 node chunks seems overkill.\n" - ">=20\n" + "> \n" "> I just realised we were setting NEWIDLE on our node definition and that\n" "> was causing large amounts of rebalance work even with\n" - "> SD_NODES_PER_DOMAIN=3D16.\n" - ">=20\n" + "> SD_NODES_PER_DOMAIN=16.\n" + "> \n" "> After removing it and bumping SD_NODES_PER_DOMAIN to 32, things look\n" "> pretty good.\n" - ">=20\n" + "> \n" "> Perhaps we should allow an arch to override SD_NODES_PER_DOMAIN so this\n" "> extra level is only used by SGI boxes.\n" "\n" @@ -57,8 +58,7 @@ "index 8fb4245..877b9f1 100644\n" "--- a/kernel/sched.c\n" "+++ b/kernel/sched.c\n" - "@@ -7203,7 +7203,7 @@ static struct sched_domain_topology_level default_top=\n" - "ology[] =3D {\n" + "@@ -7203,7 +7203,7 @@ static struct sched_domain_topology_level default_topology[] = {\n" " #endif\n" " \t{ sd_init_CPU, cpu_cpu_mask, },\n" " #ifdef CONFIG_NUMA\n" @@ -68,4 +68,4 @@ " #endif\n" " \t{ NULL, }," -9ca077702cc3ac405573f3e40a2bb42f355a3046c93c3b49ee7c32893f174c06 +d4a5df9f4d6e0b7e0c43d331b8446e06adcaa9615767dfd80a824b7eede7bdac
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.