hotplug support for arch/arc/plat-eznps platform

hotplug support for arch/arc/plat-eznps platform

[Ofer Levi(SW)]

I'm adding hot-plug support for the above arch and ran into performance issue with execution of 
partition_sched_domains ()  - About 0.5 sec per cpu, which is unacceptable with the arch supported 4k cpus.
To my limited understanding, on the plat-eznps arch, where each cpu is always running a single threaded process in 
isolation mode, the above call is not necessary,
Can you please confirm (or reject) my understanding? If I'm wrong short explanation will be appreciated.
If I'm correct, I will be grateful if you can point me to how to skip this call in a way acceptable by community.

Thank you.
-Ofer

Re: hotplug support for arch/arc/plat-eznps platform

[Peter Zijlstra]

On Sun, Aug 06, 2017 at 05:53:37AM +0000, Ofer Levi(SW) wrote:
> I'm adding hot-plug support for the above arch and ran into performance issue with execution of 
> partition_sched_domains ()  - About 0.5 sec per cpu, which is unacceptable with the arch supported 4k cpus.
> To my limited understanding, on the plat-eznps arch, where each cpu is always running a single threaded process in 
> isolation mode, the above call is not necessary,
> Can you please confirm (or reject) my understanding? If I'm wrong short explanation will be appreciated.
> If I'm correct, I will be grateful if you can point me to how to skip this call in a way acceptable by community.

You've failed to explain why you think hotplug should be a performance
critical path.

I'm also not seeing how it would be different from boot; you'd be
looking at a similar cost for SMP bringup.

RE: hotplug support for arch/arc/plat-eznps platform

[Ofer Levi(SW)]

> You've failed to explain why you think hotplug should be a performance
> critical path.
1. hotplug bring up of 4K cpus takes 40 minutes.  Way too much for any user.
2. plat-eznps is a network processor, where bring up time is sensitive.

> I'm also not seeing how it would be different from boot; you'd be
> looking at a similar cost for SMP bringup.
bring up time of 4k cpus during kernel boot takes 4.5 minutes. 
The function in question is performed only when smp init was performed. 
If I understand correctly, whatever this function is doing is performed after all cpus 
were brought up during kernel boot.


Thanks
-Ofer


 On Monday, August 7, 2017 11:34 AM +0000, Peter Zijlstra wrote:
> On Sun, Aug 06, 2017 at 05:53:37AM +0000, Ofer Levi(SW) wrote:
> > I'm adding hot-plug support for the above arch and ran into performance
> issue with execution of
> > partition_sched_domains ()  - About 0.5 sec per cpu, which is unacceptable
> with the arch supported 4k cpus.
> > To my limited understanding, on the plat-eznps arch, where each cpu is
> always running a single threaded process in
> > isolation mode, the above call is not necessary,
> > Can you please confirm (or reject) my understanding? If I'm wrong short
> explanation will be appreciated.
> > If I'm correct, I will be grateful if you can point me to how to skip this call in
> a way acceptable by community.
> 
> You've failed to explain why you think hotplug should be a performance
> critical path.
> 
> I'm also not seeing how it would be different from boot; you'd be
> looking at a similar cost for SMP bringup.

Re: hotplug support for arch/arc/plat-eznps platform

[Peter Zijlstra]

On Mon, Aug 07, 2017 at 01:41:38PM +0000, Ofer Levi(SW) wrote:
> > You've failed to explain why you think hotplug should be a performance
> > critical path.
> 1. hotplug bring up of 4K cpus takes 40 minutes.  Way too much for any user.
> 2. plat-eznps is a network processor, where bring up time is sensitive.

But who is doing actual hotplug? Why would you ever unplug or plug a CPU
in a time critical situation?

> > I'm also not seeing how it would be different from boot; you'd be
> > looking at a similar cost for SMP bringup.
> bring up time of 4k cpus during kernel boot takes 4.5 minutes. 
> The function in question is performed only when smp init was performed. 
> If I understand correctly, whatever this function is doing is performed after all cpus 
> were brought up during kernel boot.

Doesn't make sense. If you look at smp_init() boot brings up the CPUs
one at a time.

So how can boot be different than hot-pugging them?

RE: hotplug support for arch/arc/plat-eznps platform

[Ofer Levi(SW)]

> On Monday, August 7, 2017 6:10 PM +0000, Ofer Levi(SW) wrote:
> 
> On Mon, Aug 07, 2017 at 01:41:38PM +0000, Ofer Levi(SW) wrote:
> > > You've failed to explain why you think hotplug should be a
> > > performance critical path.
> > 1. hotplug bring up of 4K cpus takes 40 minutes.  Way too much for any
> user.
> > 2. plat-eznps is a network processor, where bring up time is sensitive.
> 
> But who is doing actual hotplug? Why would you ever unplug or plug a CPU in
> a time critical situation?

The idea behind implementing hotplug for this arch is to shorten time to traffic processing. 
This way instead of waiting ~5 min for all cpus to boot, application running on cpu 0 will 
Loop booting other cpus and assigning  the traffic processing application to it. 
Outgoing traffic will build up until all cpus are up and running full traffic rate.
This method allow for traffic processing to start after ~20 sec instead of the 5 min.

> 
> > > I'm also not seeing how it would be different from boot; you'd be
> > > looking at a similar cost for SMP bringup.
> > bring up time of 4k cpus during kernel boot takes 4.5 minutes.
> > The function in question is performed only when smp init was performed.
> > If I understand correctly, whatever this function is doing is
> > performed after all cpus were brought up during kernel boot.
> 
> Doesn't make sense. If you look at smp_init() boot brings up the CPUs one at
> a time.
> 
> So how can boot be different than hot-pugging them?

Please have a look at following code kernel/sched/core.c, sched_cpu_activate() :

	if (sched_smp_initialized) {
		sched_domains_numa_masks_set(cpu);
		cpuset_cpu_active();
	}
The cpuset_cpu_active call eventually leads to the function in question partition_sched_domains()
When cold-booting cpus the sched_smp_initialized flag is false and therefore partition_sched_domains is not executing.

This leads me back to my questions


Thanks.

Re: hotplug support for arch/arc/plat-eznps platform

[Peter Zijlstra]

On Tue, Aug 08, 2017 at 06:49:39AM +0000, Ofer Levi(SW) wrote:

> The idea behind implementing hotplug for this arch is to shorten time
> to traffic processing.  This way instead of waiting ~5 min for all
> cpus to boot, application running on cpu 0 will Loop booting other
> cpus and assigning  the traffic processing application to it.
> Outgoing traffic will build up until all cpus are up and running full
> traffic rate.  This method allow for traffic processing to start after
> ~20 sec instead of the 5 min.

Ah, ok. So only online is ever used. Offline is a whole other can of
worms.

> > So how can boot be different than hot-pugging them?
> 
> Please have a look at following code kernel/sched/core.c, sched_cpu_activate() :
> 
> 	if (sched_smp_initialized) {
> 		sched_domains_numa_masks_set(cpu);
> 		cpuset_cpu_active();
> 	}

Ah, cute, I totally missed we did that. Yes that avoids endless domain
rebuilds on boot.

> The cpuset_cpu_active call eventually leads to the function in
> question partition_sched_domains() When cold-booting cpus the
> sched_smp_initialized flag is false and therefore
> partition_sched_domains is not executing.

So you're booting with "maxcpus=1" to only online the one. And then you
want to online the rest once userspace runs.

There's two possibilities. The one I prefer (but which appears the most
broken with the current code) is using the cpuset controller.

1)

  Once you're up and running with a single CPU do:

  $ mkdir /cgroup
  $ mount none /cgroup -t cgroup -o cpuset
  $ echo 0 > /cgroup/cpuset.sched_load_balance
  $ for ((i=1;i<4096;i++))
    do
      echo 1 > /sys/devices/system/cpu/cpu$i/online;
    done

  And then, if you want load-balancing, you can re-enable it globally,
  or only on a subset of CPUs.


2)

  The alternative is to use "isolcpus=1-4095" to completely kill
  load-balancing. This more or less works with the current code,
  except that it will keep rebuilding the CPU0 sched-domain, which
  is somewhat pointless (also fixed by the below patch).

  The reason I don't particularly like this option is that its boot time
  only, you cannot reconfigure your system at runtime, but that might
  be good enough for you.


With the attached patch, either option generates (I only have 40 CPUs):

[   44.305563] CPU0 attaching NULL sched-domain.
[   51.954872] SMP alternatives: switching to SMP code
[   51.976923] x86: Booting SMP configuration:
[   51.981602] smpboot: Booting Node 0 Processor 1 APIC 0x2
[   52.057756] microcode: sig=0x306e4, pf=0x1, revision=0x416
[   52.064740] microcode: updated to revision 0x428, date = 2014-05-29
[   52.080854] smpboot: Booting Node 0 Processor 2 APIC 0x4
[   52.164124] smpboot: Booting Node 0 Processor 3 APIC 0x6
[   52.244615] smpboot: Booting Node 0 Processor 4 APIC 0x8
[   52.324564] smpboot: Booting Node 0 Processor 5 APIC 0x10
[   52.405407] smpboot: Booting Node 0 Processor 6 APIC 0x12
[   52.485460] smpboot: Booting Node 0 Processor 7 APIC 0x14
[   52.565333] smpboot: Booting Node 0 Processor 8 APIC 0x16
[   52.645364] smpboot: Booting Node 0 Processor 9 APIC 0x18
[   52.725314] smpboot: Booting Node 1 Processor 10 APIC 0x20
[   52.827517] smpboot: Booting Node 1 Processor 11 APIC 0x22
[   52.912271] smpboot: Booting Node 1 Processor 12 APIC 0x24
[   52.996101] smpboot: Booting Node 1 Processor 13 APIC 0x26
[   53.081239] smpboot: Booting Node 1 Processor 14 APIC 0x28
[   53.164990] smpboot: Booting Node 1 Processor 15 APIC 0x30
[   53.250146] smpboot: Booting Node 1 Processor 16 APIC 0x32
[   53.333894] smpboot: Booting Node 1 Processor 17 APIC 0x34
[   53.419026] smpboot: Booting Node 1 Processor 18 APIC 0x36
[   53.502820] smpboot: Booting Node 1 Processor 19 APIC 0x38
[   53.587938] smpboot: Booting Node 0 Processor 20 APIC 0x1
[   53.659828] microcode: sig=0x306e4, pf=0x1, revision=0x428
[   53.674857] smpboot: Booting Node 0 Processor 21 APIC 0x3
[   53.756346] smpboot: Booting Node 0 Processor 22 APIC 0x5
[   53.836793] smpboot: Booting Node 0 Processor 23 APIC 0x7
[   53.917753] smpboot: Booting Node 0 Processor 24 APIC 0x9
[   53.998717] smpboot: Booting Node 0 Processor 25 APIC 0x11
[   54.079674] smpboot: Booting Node 0 Processor 26 APIC 0x13
[   54.160636] smpboot: Booting Node 0 Processor 27 APIC 0x15
[   54.241592] smpboot: Booting Node 0 Processor 28 APIC 0x17
[   54.322553] smpboot: Booting Node 0 Processor 29 APIC 0x19
[   54.403487] smpboot: Booting Node 1 Processor 30 APIC 0x21
[   54.487676] smpboot: Booting Node 1 Processor 31 APIC 0x23
[   54.571921] smpboot: Booting Node 1 Processor 32 APIC 0x25
[   54.656508] smpboot: Booting Node 1 Processor 33 APIC 0x27
[   54.740835] smpboot: Booting Node 1 Processor 34 APIC 0x29
[   54.824466] smpboot: Booting Node 1 Processor 35 APIC 0x31
[   54.908374] smpboot: Booting Node 1 Processor 36 APIC 0x33
[   54.992322] smpboot: Booting Node 1 Processor 37 APIC 0x35
[   55.076333] smpboot: Booting Node 1 Processor 38 APIC 0x37
[   55.160249] smpboot: Booting Node 1 Processor 39 APIC 0x39


---
Subject: sched,cpuset: Avoid spurious/wrong domain rebuilds

When disabling cpuset.sched_load_balance we expect to be able to online
CPUs without generating sched_domains. However this is currently
completely broken.

What happens is that we generate the sched_domains and then destroy
them. This is because of the spurious 'default' domain build in
cpuset_update_active_cpus(). That builds a single machine wide domain
and then schedules a work to build the 'real' domains. The work then
finds there are _no_ domains and destroys the lot again.

Furthermore, if there actually were cpusets, building the machine wide
domain is actively wrong, because it would allow tasks to 'escape' their
cpuset. Also I don't think its needed, the scheduler really should
respect the active mask.

Also (this should probably be a separate patch) fix
partition_sched_domains() to try and preserve the existing machine wide
domain instead of unconditionally destroying it. We do this by
attempting to allocate the new single domain, only when that fails to we
reuse the fallback_doms.

Cc: Tejun Heo <tj@kernel.org>
Almost-Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 kernel/cgroup/cpuset.c  |  6 ------
 kernel/sched/topology.c | 15 ++++++++++++---
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index ca8376e5008c..e557cdba2350 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -2342,13 +2342,7 @@ void cpuset_update_active_cpus(void)
 	 * We're inside cpu hotplug critical region which usually nests
 	 * inside cgroup synchronization.  Bounce actual hotplug processing
 	 * to a work item to avoid reverse locking order.
-	 *
-	 * We still need to do partition_sched_domains() synchronously;
-	 * otherwise, the scheduler will get confused and put tasks to the
-	 * dead CPU.  Fall back to the default single domain.
-	 * cpuset_hotplug_workfn() will rebuild it as necessary.
 	 */
-	partition_sched_domains(1, NULL, NULL);
 	schedule_work(&cpuset_hotplug_work);
 }
 
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 79895aec281e..1b74b2cc5dba 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -1854,7 +1854,17 @@ void partition_sched_domains(int ndoms_new, cpumask_var_t doms_new[],
 	/* Let the architecture update CPU core mappings: */
 	new_topology = arch_update_cpu_topology();
 
-	n = doms_new ? ndoms_new : 0;
+	if (!doms_new) {
+		WARN_ON_ONCE(dattr_new);
+		n = 0;
+		doms_new = alloc_sched_domains(1);
+		if (doms_new) {
+			n = 1;
+			cpumask_andnot(doms_new[0], cpu_active_mask, cpu_isolated_map);
+		}
+	} else {
+		n = ndoms_new;
+	}
 
 	/* Destroy deleted domains: */
 	for (i = 0; i < ndoms_cur; i++) {
@@ -1870,11 +1880,10 @@ void partition_sched_domains(int ndoms_new, cpumask_var_t doms_new[],
 	}
 
 	n = ndoms_cur;
-	if (doms_new == NULL) {
+	if (!doms_new) {
 		n = 0;
 		doms_new = &fallback_doms;
 		cpumask_andnot(doms_new[0], cpu_active_mask, cpu_isolated_map);
-		WARN_ON_ONCE(dattr_new);
 	}
 
 	/* Build new domains: */

RE: hotplug support for arch/arc/plat-eznps platform

[Ofer Levi(SW)]

I appreciate your effort and detailed reply, however I'm still experiencing  performance hit at 
partition_sched_domains(). It seems the issue is due to the large magnitude of cpus. 
I used he suggested method 2, patched in the diffs and used the command line switch isolcpus to
kill load-balancing.
It did save few hundredth of a sec per cpu. When I limited number of available cpus 
(using present and possible cpus ) to 48, it did reduced dramatically this function execution time:

With 4K available cpus :
[   48.890000] ## CPU16 LIVE ##: Executing Code...
[   48.910000] partition_sched_domains start
[   49.360000] partition_sched_domains end

With 48 available cpus:
[   36.950000] ## CPU16 LIVE ##: Executing Code...
[   36.950000] partition_sched_domains start
[   36.960000] partition_sched_domains end

Note that I currently use kernel version: 4.8.0.17.0600.00.0000, if this has any influence.
Would appreciate your thoughts.


Thanks
-Ofer



> -----Original Message-----
> From: Peter Zijlstra [mailto:peterz@infradead.org]
> Sent: Tuesday, August 8, 2017 1:16 PM
> To: Ofer Levi(SW) <oferle@mellanox.com>
> Cc: rusty@rustcorp.com.au; mingo@redhat.com;
> Vineet.Gupta1@synopsys.com; linux-kernel@vger.kernel.org; Tejun Heo
> <tj@kernel.org>
> Subject: Re: hotplug support for arch/arc/plat-eznps platform
> 
> On Tue, Aug 08, 2017 at 06:49:39AM +0000, Ofer Levi(SW) wrote:
> 
> > The idea behind implementing hotplug for this arch is to shorten time
> > to traffic processing.  This way instead of waiting ~5 min for all
> > cpus to boot, application running on cpu 0 will Loop booting other
> > cpus and assigning  the traffic processing application to it.
> > Outgoing traffic will build up until all cpus are up and running full
> > traffic rate.  This method allow for traffic processing to start after
> > ~20 sec instead of the 5 min.
> 
> Ah, ok. So only online is ever used. Offline is a whole other can of worms.
> 
> > > So how can boot be different than hot-pugging them?
> >
> > Please have a look at following code kernel/sched/core.c,
> sched_cpu_activate() :
> >
> > 	if (sched_smp_initialized) {
> > 		sched_domains_numa_masks_set(cpu);
> > 		cpuset_cpu_active();
> > 	}
> 
> Ah, cute, I totally missed we did that. Yes that avoids endless domain rebuilds
> on boot.
> 
> > The cpuset_cpu_active call eventually leads to the function in
> > question partition_sched_domains() When cold-booting cpus the
> > sched_smp_initialized flag is false and therefore
> > partition_sched_domains is not executing.
> 
> So you're booting with "maxcpus=1" to only online the one. And then you
> want to online the rest once userspace runs.
> 
> There's two possibilities. The one I prefer (but which appears the most
> broken with the current code) is using the cpuset controller.
> 
> 1)
> 
>   Once you're up and running with a single CPU do:
> 
>   $ mkdir /cgroup
>   $ mount none /cgroup -t cgroup -o cpuset
>   $ echo 0 > /cgroup/cpuset.sched_load_balance
>   $ for ((i=1;i<4096;i++))
>     do
>       echo 1 > /sys/devices/system/cpu/cpu$i/online;
>     done
> 
>   And then, if you want load-balancing, you can re-enable it globally,
>   or only on a subset of CPUs.
> 
> 
> 2)
> 
>   The alternative is to use "isolcpus=1-4095" to completely kill
>   load-balancing. This more or less works with the current code,
>   except that it will keep rebuilding the CPU0 sched-domain, which
>   is somewhat pointless (also fixed by the below patch).
> 
>   The reason I don't particularly like this option is that its boot time
>   only, you cannot reconfigure your system at runtime, but that might
>   be good enough for you.
> 
> 
> With the attached patch, either option generates (I only have 40 CPUs):
> 
> [   44.305563] CPU0 attaching NULL sched-domain.
> [   51.954872] SMP alternatives: switching to SMP code
> [   51.976923] x86: Booting SMP configuration:
> [   51.981602] smpboot: Booting Node 0 Processor 1 APIC 0x2
> [   52.057756] microcode: sig=0x306e4, pf=0x1, revision=0x416
> [   52.064740] microcode: updated to revision 0x428, date = 2014-05-29
> [   52.080854] smpboot: Booting Node 0 Processor 2 APIC 0x4
> [   52.164124] smpboot: Booting Node 0 Processor 3 APIC 0x6
> [   52.244615] smpboot: Booting Node 0 Processor 4 APIC 0x8
> [   52.324564] smpboot: Booting Node 0 Processor 5 APIC 0x10
> [   52.405407] smpboot: Booting Node 0 Processor 6 APIC 0x12
> [   52.485460] smpboot: Booting Node 0 Processor 7 APIC 0x14
> [   52.565333] smpboot: Booting Node 0 Processor 8 APIC 0x16
> [   52.645364] smpboot: Booting Node 0 Processor 9 APIC 0x18
> [   52.725314] smpboot: Booting Node 1 Processor 10 APIC 0x20
> [   52.827517] smpboot: Booting Node 1 Processor 11 APIC 0x22
> [   52.912271] smpboot: Booting Node 1 Processor 12 APIC 0x24
> [   52.996101] smpboot: Booting Node 1 Processor 13 APIC 0x26
> [   53.081239] smpboot: Booting Node 1 Processor 14 APIC 0x28
> [   53.164990] smpboot: Booting Node 1 Processor 15 APIC 0x30
> [   53.250146] smpboot: Booting Node 1 Processor 16 APIC 0x32
> [   53.333894] smpboot: Booting Node 1 Processor 17 APIC 0x34
> [   53.419026] smpboot: Booting Node 1 Processor 18 APIC 0x36
> [   53.502820] smpboot: Booting Node 1 Processor 19 APIC 0x38
> [   53.587938] smpboot: Booting Node 0 Processor 20 APIC 0x1
> [   53.659828] microcode: sig=0x306e4, pf=0x1, revision=0x428
> [   53.674857] smpboot: Booting Node 0 Processor 21 APIC 0x3
> [   53.756346] smpboot: Booting Node 0 Processor 22 APIC 0x5
> [   53.836793] smpboot: Booting Node 0 Processor 23 APIC 0x7
> [   53.917753] smpboot: Booting Node 0 Processor 24 APIC 0x9
> [   53.998717] smpboot: Booting Node 0 Processor 25 APIC 0x11
> [   54.079674] smpboot: Booting Node 0 Processor 26 APIC 0x13
> [   54.160636] smpboot: Booting Node 0 Processor 27 APIC 0x15
> [   54.241592] smpboot: Booting Node 0 Processor 28 APIC 0x17
> [   54.322553] smpboot: Booting Node 0 Processor 29 APIC 0x19
> [   54.403487] smpboot: Booting Node 1 Processor 30 APIC 0x21
> [   54.487676] smpboot: Booting Node 1 Processor 31 APIC 0x23
> [   54.571921] smpboot: Booting Node 1 Processor 32 APIC 0x25
> [   54.656508] smpboot: Booting Node 1 Processor 33 APIC 0x27
> [   54.740835] smpboot: Booting Node 1 Processor 34 APIC 0x29
> [   54.824466] smpboot: Booting Node 1 Processor 35 APIC 0x31
> [   54.908374] smpboot: Booting Node 1 Processor 36 APIC 0x33
> [   54.992322] smpboot: Booting Node 1 Processor 37 APIC 0x35
> [   55.076333] smpboot: Booting Node 1 Processor 38 APIC 0x37
> [   55.160249] smpboot: Booting Node 1 Processor 39 APIC 0x39
> 
> 
> ---
> Subject: sched,cpuset: Avoid spurious/wrong domain rebuilds
> 
> When disabling cpuset.sched_load_balance we expect to be able to online
> CPUs without generating sched_domains. However this is currently
> completely broken.
> 
> What happens is that we generate the sched_domains and then destroy
> them. This is because of the spurious 'default' domain build in
> cpuset_update_active_cpus(). That builds a single machine wide domain and
> then schedules a work to build the 'real' domains. The work then finds there
> are _no_ domains and destroys the lot again.
> 
> Furthermore, if there actually were cpusets, building the machine wide
> domain is actively wrong, because it would allow tasks to 'escape' their
> cpuset. Also I don't think its needed, the scheduler really should respect the
> active mask.
> 
> Also (this should probably be a separate patch) fix
> partition_sched_domains() to try and preserve the existing machine wide
> domain instead of unconditionally destroying it. We do this by attempting to
> allocate the new single domain, only when that fails to we reuse the
> fallback_doms.
> 
> Cc: Tejun Heo <tj@kernel.org>
> Almost-Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
>  kernel/cgroup/cpuset.c  |  6 ------
>  kernel/sched/topology.c | 15 ++++++++++++---
>  2 files changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index
> ca8376e5008c..e557cdba2350 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -2342,13 +2342,7 @@ void cpuset_update_active_cpus(void)
>  	 * We're inside cpu hotplug critical region which usually nests
>  	 * inside cgroup synchronization.  Bounce actual hotplug processing
>  	 * to a work item to avoid reverse locking order.
> -	 *
> -	 * We still need to do partition_sched_domains() synchronously;
> -	 * otherwise, the scheduler will get confused and put tasks to the
> -	 * dead CPU.  Fall back to the default single domain.
> -	 * cpuset_hotplug_workfn() will rebuild it as necessary.
>  	 */
> -	partition_sched_domains(1, NULL, NULL);
>  	schedule_work(&cpuset_hotplug_work);
>  }
> 
> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index
> 79895aec281e..1b74b2cc5dba 100644
> --- a/kernel/sched/topology.c
> +++ b/kernel/sched/topology.c
> @@ -1854,7 +1854,17 @@ void partition_sched_domains(int ndoms_new,
> cpumask_var_t doms_new[],
>  	/* Let the architecture update CPU core mappings: */
>  	new_topology = arch_update_cpu_topology();
> 
> -	n = doms_new ? ndoms_new : 0;
> +	if (!doms_new) {
> +		WARN_ON_ONCE(dattr_new);
> +		n = 0;
> +		doms_new = alloc_sched_domains(1);
> +		if (doms_new) {
> +			n = 1;
> +			cpumask_andnot(doms_new[0], cpu_active_mask,
> cpu_isolated_map);
> +		}
> +	} else {
> +		n = ndoms_new;
> +	}
> 
>  	/* Destroy deleted domains: */
>  	for (i = 0; i < ndoms_cur; i++) {
> @@ -1870,11 +1880,10 @@ void partition_sched_domains(int ndoms_new,
> cpumask_var_t doms_new[],
>  	}
> 
>  	n = ndoms_cur;
> -	if (doms_new == NULL) {
> +	if (!doms_new) {
>  		n = 0;
>  		doms_new = &fallback_doms;
>  		cpumask_andnot(doms_new[0], cpu_active_mask,
> cpu_isolated_map);
> -		WARN_ON_ONCE(dattr_new);
>  	}
> 
>  	/* Build new domains: */

Re: hotplug support for arch/arc/plat-eznps platform

[Peter Zijlstra]

On Wed, Aug 09, 2017 at 03:19:02PM +0000, Ofer Levi(SW) wrote:
> I appreciate your effort and detailed reply, however I'm still experiencing  performance hit at 
> partition_sched_domains(). It seems the issue is due to the large magnitude of cpus. 
> I used he suggested method 2, patched in the diffs and used the command line switch isolcpus to
> kill load-balancing.
> It did save few hundredth of a sec per cpu. When I limited number of available cpus 
> (using present and possible cpus ) to 48, it did reduced dramatically this function execution time:
> 
> With 4K available cpus :
> [   48.890000] ## CPU16 LIVE ##: Executing Code...
> [   48.910000] partition_sched_domains start
> [   49.360000] partition_sched_domains end
> 
> With 48 available cpus:
> [   36.950000] ## CPU16 LIVE ##: Executing Code...
> [   36.950000] partition_sched_domains start
> [   36.960000] partition_sched_domains end
> 
> Note that I currently use kernel version: 4.8.0.17.0600.00.0000, if this has any influence.
> Would appreciate your thoughts.
> 

Does something like this cure things? It seems we're doing a
possible_cpus iteration for sysctl cruft, and that will most certainly
hurt on your little toy :-)

Not sure what the more generic solution to that would be, but the below
avoids it for isolcpus.

---
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -85,6 +85,7 @@ int sysctl_sched_rt_runtime = 950000;
 
 /* CPUs with isolated domains */
 cpumask_var_t cpu_isolated_map;
+cpumask_var_t non_isolated_cpus;
 
 /*
  * __task_rq_lock - lock the rq @p resides on.
@@ -5685,8 +5686,6 @@ static inline void sched_init_smt(void)
 
 void __init sched_init_smp(void)
 {
-	cpumask_var_t non_isolated_cpus;
-
 	alloc_cpumask_var(&non_isolated_cpus, GFP_KERNEL);
 
 	sched_init_numa();
@@ -5697,17 +5696,17 @@ void __init sched_init_smp(void)
 	 * happen.
 	 */
 	mutex_lock(&sched_domains_mutex);
-	sched_init_domains(cpu_active_mask);
 	cpumask_andnot(non_isolated_cpus, cpu_possible_mask, cpu_isolated_map);
 	if (cpumask_empty(non_isolated_cpus))
 		cpumask_set_cpu(smp_processor_id(), non_isolated_cpus);
+
+	sched_init_domains(cpu_active_mask);
 	mutex_unlock(&sched_domains_mutex);
 
 	/* Move init over to a non-isolated CPU */
 	if (set_cpus_allowed_ptr(current, non_isolated_cpus) < 0)
 		BUG();
 	sched_init_granularity();
-	free_cpumask_var(non_isolated_cpus);
 
 	init_sched_rt_class();
 	init_sched_dl_class();
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -327,6 +327,8 @@ static struct ctl_table *sd_alloc_ctl_cp
 	return table;
 }
 
+extern cpumask_var_t non_isolated_cpus;
+
 static struct ctl_table_header *sd_sysctl_header;
 void register_sched_domain_sysctl(void)
 {
@@ -340,7 +342,7 @@ void register_sched_domain_sysctl(void)
 	if (entry == NULL)
 		return;
 
-	for_each_possible_cpu(i) {
+	for_each_cpu(i, non_isolated_cpus) {
 		snprintf(buf, 32, "cpu%d", i);
 		entry->procname = kstrdup(buf, GFP_KERNEL);
 		entry->mode = 0555;

RE: hotplug support for arch/arc/plat-eznps platform

[Ofer Levi(SW)]

Well, this definitely have pleased the little toy :)
Thank you. I really appreciate your time and effort.

If I may, one more newbie question. What do I need to do for the two patches to find 
their way into formal kernel code?

Thanks
-Ofer



> -----Original Message-----
> From: Peter Zijlstra [mailto:peterz@infradead.org]
> Sent: Wednesday, August 9, 2017 6:35 PM
> To: Ofer Levi(SW) <oferle@mellanox.com>
> Cc: rusty@rustcorp.com.au; mingo@redhat.com;
> Vineet.Gupta1@synopsys.com; linux-kernel@vger.kernel.org; Tejun Heo
> <tj@kernel.org>
> Subject: Re: hotplug support for arch/arc/plat-eznps platform
> 
> On Wed, Aug 09, 2017 at 03:19:02PM +0000, Ofer Levi(SW) wrote:
> > I appreciate your effort and detailed reply, however I'm still
> > experiencing  performance hit at partition_sched_domains(). It seems the
> issue is due to the large magnitude of cpus.
> > I used he suggested method 2, patched in the diffs and used the
> > command line switch isolcpus to kill load-balancing.
> > It did save few hundredth of a sec per cpu. When I limited number of
> > available cpus (using present and possible cpus ) to 48, it did reduced
> dramatically this function execution time:
> >
> > With 4K available cpus :
> > [   48.890000] ## CPU16 LIVE ##: Executing Code...
> > [   48.910000] partition_sched_domains start
> > [   49.360000] partition_sched_domains end
> >
> > With 48 available cpus:
> > [   36.950000] ## CPU16 LIVE ##: Executing Code...
> > [   36.950000] partition_sched_domains start
> > [   36.960000] partition_sched_domains end
> >
> > Note that I currently use kernel version: 4.8.0.17.0600.00.0000, if this has
> any influence.
> > Would appreciate your thoughts.
> >
> 
> Does something like this cure things? It seems we're doing a possible_cpus
> iteration for sysctl cruft, and that will most certainly hurt on your little toy :-)
> 
> Not sure what the more generic solution to that would be, but the below
> avoids it for isolcpus.
> 
> ---
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -85,6 +85,7 @@ int sysctl_sched_rt_runtime = 950000;
> 
>  /* CPUs with isolated domains */
>  cpumask_var_t cpu_isolated_map;
> +cpumask_var_t non_isolated_cpus;
> 
>  /*
>   * __task_rq_lock - lock the rq @p resides on.
> @@ -5685,8 +5686,6 @@ static inline void sched_init_smt(void)
> 
>  void __init sched_init_smp(void)
>  {
> -	cpumask_var_t non_isolated_cpus;
> -
>  	alloc_cpumask_var(&non_isolated_cpus, GFP_KERNEL);
> 
>  	sched_init_numa();
> @@ -5697,17 +5696,17 @@ void __init sched_init_smp(void)
>  	 * happen.
>  	 */
>  	mutex_lock(&sched_domains_mutex);
> -	sched_init_domains(cpu_active_mask);
>  	cpumask_andnot(non_isolated_cpus, cpu_possible_mask,
> cpu_isolated_map);
>  	if (cpumask_empty(non_isolated_cpus))
>  		cpumask_set_cpu(smp_processor_id(), non_isolated_cpus);
> +
> +	sched_init_domains(cpu_active_mask);
>  	mutex_unlock(&sched_domains_mutex);
> 
>  	/* Move init over to a non-isolated CPU */
>  	if (set_cpus_allowed_ptr(current, non_isolated_cpus) < 0)
>  		BUG();
>  	sched_init_granularity();
> -	free_cpumask_var(non_isolated_cpus);
> 
>  	init_sched_rt_class();
>  	init_sched_dl_class();
> --- a/kernel/sched/debug.c
> +++ b/kernel/sched/debug.c
> @@ -327,6 +327,8 @@ static struct ctl_table *sd_alloc_ctl_cp
>  	return table;
>  }
> 
> +extern cpumask_var_t non_isolated_cpus;
> +
>  static struct ctl_table_header *sd_sysctl_header;  void
> register_sched_domain_sysctl(void)
>  {
> @@ -340,7 +342,7 @@ void register_sched_domain_sysctl(void)
>  	if (entry == NULL)
>  		return;
> 
> -	for_each_possible_cpu(i) {
> +	for_each_cpu(i, non_isolated_cpus) {
>  		snprintf(buf, 32, "cpu%d", i);
>  		entry->procname = kstrdup(buf, GFP_KERNEL);
>  		entry->mode = 0555;

Re: hotplug support for arch/arc/plat-eznps platform

[Peter Zijlstra]

On Thu, Aug 10, 2017 at 07:40:16AM +0000, Ofer Levi(SW) wrote:
> Well, this definitely have pleased the little toy :)
> Thank you. I really appreciate your time and effort.
> 
> If I may, one more newbie question. What do I need to do for the two patches to find 
> their way into formal kernel code?

I'll split the first patch into two separate patches and line them up.

I'm not sure about this last patch, I'll speak with Ingo once he's back
to see what would be the thing to do here.

I suspect we can make it work, that sysctl stuff is only debug crud
after all and that should never get in the way of getting work done.

RE: hotplug support for arch/arc/plat-eznps platform

[Ofer Levi(SW)]

Great, thanks.

> -----Original Message-----
> From: Peter Zijlstra [mailto:peterz@infradead.org]
> Sent: Thursday, August 10, 2017 12:19 PM
> To: Ofer Levi(SW) <oferle@mellanox.com>
> Cc: rusty@rustcorp.com.au; mingo@redhat.com;
> Vineet.Gupta1@synopsys.com; linux-kernel@vger.kernel.org; Tejun Heo
> <tj@kernel.org>
> Subject: Re: hotplug support for arch/arc/plat-eznps platform
> 
> On Thu, Aug 10, 2017 at 07:40:16AM +0000, Ofer Levi(SW) wrote:
> > Well, this definitely have pleased the little toy :) Thank you. I
> > really appreciate your time and effort.
> >
> > If I may, one more newbie question. What do I need to do for the two
> > patches to find their way into formal kernel code?
> 
> I'll split the first patch into two separate patches and line them up.
> 
> I'm not sure about this last patch, I'll speak with Ingo once he's back to see
> what would be the thing to do here.
> 
> I suspect we can make it work, that sysctl stuff is only debug crud after all and
> that should never get in the way of getting work done.

Re: hotplug support for arch/arc/plat-eznps platform

[Peter Zijlstra]

On Thu, Aug 10, 2017 at 11:19:05AM +0200, Peter Zijlstra wrote:
> On Thu, Aug 10, 2017 at 07:40:16AM +0000, Ofer Levi(SW) wrote:
> > Well, this definitely have pleased the little toy :)
> > Thank you. I really appreciate your time and effort.
> > 
> > If I may, one more newbie question. What do I need to do for the two patches to find 
> > their way into formal kernel code?
> 
> I'll split the first patch into two separate patches and line them up.
> 
> I'm not sure about this last patch, I'll speak with Ingo once he's back
> to see what would be the thing to do here.
> 
> I suspect we can make it work, that sysctl stuff is only debug crud
> after all and that should never get in the way of getting work done.

Can you test this instead of the second patch? It should have the same
effect.

BTW, what physical size does your toy have? I'm thinking its less than
multiple racks worth like the SGI systems were.

---
Subject: sched/debug: Optimize sched_domain sysctl generation
From: Peter Zijlstra <peterz@infradead.org>
Date: Thu Aug 10 17:10:26 CEST 2017

Currently we unconditionally destroy all sysctl bits and regenerate
them after we've rebuild the domains (even if that rebuild is a
no-op).

And since we unconditionally (re)build the sysctl for all possible
CPUs, onlining all CPUs gets us O(n^2) time. Instead change this to
only rebuild the bits for CPUs we've actually installed new domains
on.

Reported-by: "Ofer Levi(SW)" <oferle@mellanox.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 kernel/sched/debug.c    |   68 ++++++++++++++++++++++++++++++++++++++----------
 kernel/sched/sched.h    |    4 ++
 kernel/sched/topology.c |    1 
 3 files changed, 59 insertions(+), 14 deletions(-)

--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -327,38 +327,78 @@ static struct ctl_table *sd_alloc_ctl_cp
 	return table;
 }
 
+static cpumask_var_t sd_sysctl_cpus;
 static struct ctl_table_header *sd_sysctl_header;
+
 void register_sched_domain_sysctl(void)
 {
-	int i, cpu_num = num_possible_cpus();
-	struct ctl_table *entry = sd_alloc_ctl_entry(cpu_num + 1);
+	static struct ctl_table *cpu_entries;
+	static struct ctl_table **cpu_idx;
 	char buf[32];
+	int i;
+
+	if (!cpu_entries) {
+		cpu_entries = sd_alloc_ctl_entry(num_possible_cpus() + 1);
+		if (!cpu_entries)
+			return;
+
+		WARN_ON(sd_ctl_dir[0].child);
+		sd_ctl_dir[0].child = cpu_entries;
+	}
+
+	if (!cpu_idx) {
+		struct ctl_table *e = cpu_entries;
+
+		cpu_idx = kcalloc(nr_cpu_ids, sizeof(struct ctl_table*), GFP_KERNEL);
+		if (!cpu_idx)
+			return;
+
+		/* deal with sparse possible map */
+		for_each_possible_cpu(i) {
+			cpu_idx[i] = e;
+			e++;
+		}
+	}
 
-	WARN_ON(sd_ctl_dir[0].child);
-	sd_ctl_dir[0].child = entry;
+	if (!cpumask_available(sd_sysctl_cpus)) {
+		if (!alloc_cpumask_var(&sd_sysctl_cpus, GFP_KERNEL))
+			return;
 
-	if (entry == NULL)
-		return;
+		/* init to possible to not have holes in @cpu_entries */
+		cpumask_copy(sd_sysctl_cpus, cpu_possible_mask);
+	}
+
+	for_each_cpu(i, sd_sysctl_cpus) {
+		struct ctl_table *e = cpu_idx[i];
+
+		if (e->child)
+			sd_free_ctl_entry(&e->child);
+
+		if (!e->procname) {
+			snprintf(buf, 32, "cpu%d", i);
+			e->procname = kstrdup(buf, GFP_KERNEL);
+		}
+		e->mode = 0555;
+		e->child = sd_alloc_ctl_cpu_table(i);
 
-	for_each_possible_cpu(i) {
-		snprintf(buf, 32, "cpu%d", i);
-		entry->procname = kstrdup(buf, GFP_KERNEL);
-		entry->mode = 0555;
-		entry->child = sd_alloc_ctl_cpu_table(i);
-		entry++;
+		__cpumask_clear_cpu(i, sd_sysctl_cpus);
 	}
 
 	WARN_ON(sd_sysctl_header);
 	sd_sysctl_header = register_sysctl_table(sd_ctl_root);
 }
 
+void dirty_sched_domain_sysctl(int cpu)
+{
+	if (cpumask_available(sd_sysctl_cpus))
+		__cpumask_set_cpu(cpu, sd_sysctl_cpus);
+}
+
 /* may be called multiple times per register */
 void unregister_sched_domain_sysctl(void)
 {
 	unregister_sysctl_table(sd_sysctl_header);
 	sd_sysctl_header = NULL;
-	if (sd_ctl_dir[0].child)
-		sd_free_ctl_entry(&sd_ctl_dir[0].child);
 }
 #endif /* CONFIG_SYSCTL */
 #endif /* CONFIG_SMP */
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1120,11 +1120,15 @@ extern int group_balance_cpu(struct sche
 
 #if defined(CONFIG_SCHED_DEBUG) && defined(CONFIG_SYSCTL)
 void register_sched_domain_sysctl(void);
+void dirty_sched_domain_sysctl(int cpu);
 void unregister_sched_domain_sysctl(void);
 #else
 static inline void register_sched_domain_sysctl(void)
 {
 }
+static inline void dirty_sched_domain_sysctl(int cpu)
+{
+}
 static inline void unregister_sched_domain_sysctl(void)
 {
 }
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -461,6 +461,7 @@ cpu_attach_domain(struct sched_domain *s
 	rq_attach_root(rq, rd);
 	tmp = rq->sd;
 	rcu_assign_pointer(rq->sd, sd);
+	dirty_sched_domain_sysctl(cpu);
 	destroy_sched_domains(tmp);
 
 	update_top_cache_domain(cpu);

RE: hotplug support for arch/arc/plat-eznps platform

[Ofer Levi(SW)]

Sorry for the late response but this patch is a drawback,. Its back to about 0.4 sec per cpu bring up.
This is when possible, present and isolcpus are 16-4095
Most time is spent at:
register_sched_domain_sysctl() calling sd_sysctl_header = register_sysctl_table(sd_ctl_root);

[   22.150000] ## CPU16 LIVE ##: Executing Code...
[   22.170000] partition_sched_domains start
[   22.220000] register_sched_domain_sysctl start
[   22.580000] register_sched_domain_sysctl end
[   22.580000] partition_sched_domains end


> BTW, what physical size does your toy have? I'm thinking its less than
> multiple racks worth like the SGI systems were.
It's a single chip with 4K cpus, capable of 400Gbps duplex. Evaluation board is pizza box size. 

Thanks


> -----Original Message-----
> From: Peter Zijlstra [mailto:peterz@infradead.org]
> Sent: Thursday, August 10, 2017 6:45 PM
> To: Ofer Levi(SW) <oferle@mellanox.com>
> Cc: rusty@rustcorp.com.au; mingo@redhat.com;
> Vineet.Gupta1@synopsys.com; linux-kernel@vger.kernel.org; Tejun Heo
> <tj@kernel.org>
> Subject: Re: hotplug support for arch/arc/plat-eznps platform
> 
> On Thu, Aug 10, 2017 at 11:19:05AM +0200, Peter Zijlstra wrote:
> > On Thu, Aug 10, 2017 at 07:40:16AM +0000, Ofer Levi(SW) wrote:
> > > Well, this definitely have pleased the little toy :) Thank you. I
> > > really appreciate your time and effort.
> > >
> > > If I may, one more newbie question. What do I need to do for the two
> > > patches to find their way into formal kernel code?
> >
> > I'll split the first patch into two separate patches and line them up.
> >
> > I'm not sure about this last patch, I'll speak with Ingo once he's
> > back to see what would be the thing to do here.
> >
> > I suspect we can make it work, that sysctl stuff is only debug crud
> > after all and that should never get in the way of getting work done.
> 
> Can you test this instead of the second patch? It should have the same
> effect.
> 
> 
> ---
> Subject: sched/debug: Optimize sched_domain sysctl generation
> From: Peter Zijlstra <peterz@infradead.org>
> Date: Thu Aug 10 17:10:26 CEST 2017
> 
> Currently we unconditionally destroy all sysctl bits and regenerate them after
> we've rebuild the domains (even if that rebuild is a no-op).
> 
> And since we unconditionally (re)build the sysctl for all possible CPUs,
> onlining all CPUs gets us O(n^2) time. Instead change this to only rebuild the
> bits for CPUs we've actually installed new domains on.
> 
> Reported-by: "Ofer Levi(SW)" <oferle@mellanox.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
>  kernel/sched/debug.c    |   68
> ++++++++++++++++++++++++++++++++++++++----------
>  kernel/sched/sched.h    |    4 ++
>  kernel/sched/topology.c |    1
>  3 files changed, 59 insertions(+), 14 deletions(-)
> 
> --- a/kernel/sched/debug.c
> +++ b/kernel/sched/debug.c
> @@ -327,38 +327,78 @@ static struct ctl_table *sd_alloc_ctl_cp
>  	return table;
>  }
> 
> +static cpumask_var_t sd_sysctl_cpus;
>  static struct ctl_table_header *sd_sysctl_header;
> +
>  void register_sched_domain_sysctl(void)
>  {
> -	int i, cpu_num = num_possible_cpus();
> -	struct ctl_table *entry = sd_alloc_ctl_entry(cpu_num + 1);
> +	static struct ctl_table *cpu_entries;
> +	static struct ctl_table **cpu_idx;
>  	char buf[32];
> +	int i;
> +
> +	if (!cpu_entries) {
> +		cpu_entries = sd_alloc_ctl_entry(num_possible_cpus() + 1);
> +		if (!cpu_entries)
> +			return;
> +
> +		WARN_ON(sd_ctl_dir[0].child);
> +		sd_ctl_dir[0].child = cpu_entries;
> +	}
> +
> +	if (!cpu_idx) {
> +		struct ctl_table *e = cpu_entries;
> +
> +		cpu_idx = kcalloc(nr_cpu_ids, sizeof(struct ctl_table*),
> GFP_KERNEL);
> +		if (!cpu_idx)
> +			return;
> +
> +		/* deal with sparse possible map */
> +		for_each_possible_cpu(i) {
> +			cpu_idx[i] = e;
> +			e++;
> +		}
> +	}
> 
> -	WARN_ON(sd_ctl_dir[0].child);
> -	sd_ctl_dir[0].child = entry;
> +	if (!cpumask_available(sd_sysctl_cpus)) {
> +		if (!alloc_cpumask_var(&sd_sysctl_cpus, GFP_KERNEL))
> +			return;
> 
> -	if (entry == NULL)
> -		return;
> +		/* init to possible to not have holes in @cpu_entries */
> +		cpumask_copy(sd_sysctl_cpus, cpu_possible_mask);
> +	}
> +
> +	for_each_cpu(i, sd_sysctl_cpus) {
> +		struct ctl_table *e = cpu_idx[i];
> +
> +		if (e->child)
> +			sd_free_ctl_entry(&e->child);
> +
> +		if (!e->procname) {
> +			snprintf(buf, 32, "cpu%d", i);
> +			e->procname = kstrdup(buf, GFP_KERNEL);
> +		}
> +		e->mode = 0555;
> +		e->child = sd_alloc_ctl_cpu_table(i);
> 
> -	for_each_possible_cpu(i) {
> -		snprintf(buf, 32, "cpu%d", i);
> -		entry->procname = kstrdup(buf, GFP_KERNEL);
> -		entry->mode = 0555;
> -		entry->child = sd_alloc_ctl_cpu_table(i);
> -		entry++;
> +		__cpumask_clear_cpu(i, sd_sysctl_cpus);
>  	}
> 
>  	WARN_ON(sd_sysctl_header);
>  	sd_sysctl_header = register_sysctl_table(sd_ctl_root);
>  }
> 
> +void dirty_sched_domain_sysctl(int cpu) {
> +	if (cpumask_available(sd_sysctl_cpus))
> +		__cpumask_set_cpu(cpu, sd_sysctl_cpus); }
> +
>  /* may be called multiple times per register */  void
> unregister_sched_domain_sysctl(void)
>  {
>  	unregister_sysctl_table(sd_sysctl_header);
>  	sd_sysctl_header = NULL;
> -	if (sd_ctl_dir[0].child)
> -		sd_free_ctl_entry(&sd_ctl_dir[0].child);
>  }
>  #endif /* CONFIG_SYSCTL */
>  #endif /* CONFIG_SMP */
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -1120,11 +1120,15 @@ extern int group_balance_cpu(struct sche
> 
>  #if defined(CONFIG_SCHED_DEBUG) && defined(CONFIG_SYSCTL)  void
> register_sched_domain_sysctl(void);
> +void dirty_sched_domain_sysctl(int cpu);
>  void unregister_sched_domain_sysctl(void);
>  #else
>  static inline void register_sched_domain_sysctl(void)
>  {
>  }
> +static inline void dirty_sched_domain_sysctl(int cpu) { }
>  static inline void unregister_sched_domain_sysctl(void)
>  {
>  }
> --- a/kernel/sched/topology.c
> +++ b/kernel/sched/topology.c
> @@ -461,6 +461,7 @@ cpu_attach_domain(struct sched_domain *s
>  	rq_attach_root(rq, rd);
>  	tmp = rq->sd;
>  	rcu_assign_pointer(rq->sd, sd);
> +	dirty_sched_domain_sysctl(cpu);
>  	destroy_sched_domains(tmp);
> 
>  	update_top_cache_domain(cpu);