The nr_busy_cpus field of the sched_group_power is sometime different from 0 whereas the platform is fully idle. This serie fixes 3 use cases: - when some CPUs enter idle state while booting all CPUs - when a CPU is unplug and/or replug
Change since V2: - change the initialization to idle state instead of busy state so a CPU that enters idle during the build of the sched_domain will not corrupt the initialization state
Change since V1: - remove the patch for SCHED softirq on an idle core use case as it was a side effect of the other use cases.
Vincent Guittot (2): sched: fix init NOHZ_IDLE flag sched: fix update NOHZ_IDLE flag
kernel/sched/core.c | 4 +++- kernel/sched/fair.c | 2 +- 2 files changed, 4 insertions(+), 2 deletions(-)
On my smp platform which is made of 5 cores in 2 clusters, I have the nr_busy_cpu field of sched_group_power struct that is not null when the platform is fully idle. The root cause seems to be: During the boot sequence, some CPUs reach the idle loop and set their NOHZ_IDLE flag while waiting for others CPUs to boot. But the nr_busy_cpus field is initialized later with the assumption that all CPUs are in the busy state whereas some CPUs have already set their NOHZ_IDLE flag. We set the NOHZ_IDLE flag when nr_busy_cpus is initialized to 0 in order to have a coherent configuration.
The patch 2/2 protects this init against an update of NOHZ_IDLE flag because a NULL sched_domain is attached to the CPU during the build of the new sched_domain so nohz_kick_needed and set_cpu_sd_state_busy are not called and can't clear the NOHZ_IDLE flag
Signed-off-by: Vincent Guittot vincent.guittot@linaro.org --- kernel/sched/core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 26058d0..c730a4e 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -5884,7 +5884,9 @@ static void init_sched_groups_power(int cpu, struct sched_domain *sd) return;
update_group_power(sd, cpu); - atomic_set(&sg->sgp->nr_busy_cpus, sg->group_weight); + atomic_set(&sg->sgp->nr_busy_cpus, 0); + set_bit(NOHZ_IDLE, nohz_flags(cpu)); + }
int __weak arch_sd_sibling_asym_packing(void)
On 8 February 2013 19:05, Vincent Guittot vincent.guittot@linaro.org wrote:
On my smp platform which is made of 5 cores in 2 clusters, I have the nr_busy_cpu field of sched_group_power struct that is not null when the platform is fully idle. The root cause seems to be: During the boot sequence, some CPUs reach the idle loop and set their NOHZ_IDLE flag while waiting for others CPUs to boot. But the nr_busy_cpus field is initialized later with the assumption that all CPUs are in the busy state whereas some CPUs have already set their NOHZ_IDLE flag. We set the NOHZ_IDLE flag when nr_busy_cpus is initialized to 0 in order to have a coherent configuration.
The patch 2/2 protects this init against an update of NOHZ_IDLE flag because a NULL sched_domain is attached to the CPU during the build of the new sched_domain so nohz_kick_needed and set_cpu_sd_state_busy are not called and can't clear the NOHZ_IDLE flag
Hi Frederic,
With this v3, the initialization of NOHZ_IDLE and nr_busy_cpus is be protected against any race condition because the initial state is the idle state so if a cpu enters idle, it keeps the same state and we can't set a busy state until the initialization is complete thanks to the NULL domain.
Regards, Vincent
Signed-off-by: Vincent Guittot vincent.guittot@linaro.org
kernel/sched/core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 26058d0..c730a4e 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -5884,7 +5884,9 @@ static void init_sched_groups_power(int cpu, struct sched_domain *sd) return;
update_group_power(sd, cpu);
atomic_set(&sg->sgp->nr_busy_cpus, sg->group_weight);
atomic_set(&sg->sgp->nr_busy_cpus, 0);set_bit(NOHZ_IDLE, nohz_flags(cpu));}
int __weak arch_sd_sibling_asym_packing(void)
1.7.9.5
The function nohz_kick_needed modifies NOHZ_IDLE flag that is used to update the nr_busy_cpus of the sched_group. When the sched_domain are updated (during the boot or because of the unplug of a CPUs as an example) a null_domain is attached to CPUs. We have to test likely(!on_null_domain(cpu) first in order to detect such intialization step and to not modify the NOHZ_IDLE flag
Signed-off-by: Vincent Guittot vincent.guittot@linaro.org --- kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 5eea870..dac2edf 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -5695,7 +5695,7 @@ void trigger_load_balance(struct rq *rq, int cpu) likely(!on_null_domain(cpu))) raise_softirq(SCHED_SOFTIRQ); #ifdef CONFIG_NO_HZ - if (nohz_kick_needed(rq, cpu) && likely(!on_null_domain(cpu))) + if (likely(!on_null_domain(cpu)) && nohz_kick_needed(rq, cpu)) nohz_balancer_kick(cpu); #endif }
On 8 February 2013 23:35, Vincent Guittot vincent.guittot@linaro.org wrote:
The nr_busy_cpus field of the sched_group_power is sometime different from 0 whereas the platform is fully idle. This serie fixes 3 use cases:
- when some CPUs enter idle state while booting all CPUs
- when a CPU is unplug and/or replug
Applied as: fix-nr-busy-cpus-v3
-
Vincent Guittot -
Viresh Kumar