scheduler crash on Power

[Dietmar Eggemann]

On 04/08/14 04:20, Michael Ellerman wrote:
> On Fri, 2014-08-01 at 14:24 -0700, Sukadev Bhattiprolu wrote:
>> Dietmar Eggemann [dietmar.eggemann at arm.com] wrote:
>> | > ltcbrazos2-lp07 login: [  181.915974] ------------[ cut here ]------------
>> | > [  181.915991] WARNING: at ../kernel/sched/core.c:5881
>> | 
>> | This warning indicates the problem. One of the struct sched_domains does
>> | not have it's groups member set.
>> | 
>> | And its happening during a rebuild of the sched domain hierarchy, not
>> | during the initial build.
>> | 
>> | You could run your system with the following patch-let (on top of
>> | https://lkml.org/lkml/2014/7/17/288)  w/ and w/o the perf related
>> | patches (w/ CONFIG_SCHED_DEBUG enabled).
>> | 
>> | @@ -5882,6 +5882,9 @@ static void init_sched_groups_capacity(int cpu,
>> | struct sched_domain *sd)
>> |  {
>> |         struct sched_group *sg = sd->groups;
>> | 
>> | +#ifdef CONFIG_SCHED_DEBUG
>> | +       printk("sd name: %s span: %pc\n", sd->name, sd->span);
>> | +#endif
>> |         WARN_ON(!sg);
>> | 
>> |         do {
>> | 
>> | This will show if the rebuild of the sched domain hierarchy happens on
>> | both systems and hopefully indicate for which sched_domain the
>> | sd->groups is not set.
>>
>> Thanks for the patch. It appears that the NUMA sched domain does not
>> have the sd->groups set - snippet of the error (with your patch and
>> Peter's patch)
>>
>> [  181.914494] build_sched_groups: got group c000000006da0000 with cpus: 
>> [  181.914498] build_sched_groups: got group c0000000dd830000 with cpus: 
>> [  181.915234] sd name: SMT span: 8-15
>> [  181.915239] sd name: DIE span: 0-7
>> [  181.915242] sd name: NUMA span: 0-15
>> [  181.915250] ------------[ cut here ]------------
>> [  181.915253] WARNING: at ../kernel/sched/core.c:5891
>>
>> Patched code:
>>
>> 	5884 static void init_sched_groups_capacity(int cpu, struct sched_domain *sd)
>> 	5885 {
>> 	5886         struct sched_group *sg = sd->groups;
>> 	5887 
>> 	5888 #ifdef CONFIG_SCHED_DEBUG
>> 	5889         printk("sd name: %s span: %pc\n", sd->name, sd->span);
>> 	5890 #endif
>> 	5891         WARN_ON(!sg);
>>
>> Complete log below.
>>
>> I was able to bisect it down to this patch in the 24x7 patchset
>>
>> 	https://lkml.org/lkml/2014/5/27/804
>>
>> I replaced the kfree(page) calls in the patch with
>> kmem_cache_free(hv_page_cache, page).
>>
>> The problem sems to disappear if the call to create_events_from_catalog()
>> in hv_24x7_init() is skipped. I am continuing to debug the 24x7 patch.
> 
> Is that patch just clobbering memory it doesn't own and corrupting the
> scheduler data structures?

Quite likely. When the system comes up initially, it has SMT and DIE
sched domain level:

...
[    0.033832] build_sched_groups: got group c0000000e7d50000 with cpus:
[    0.033835] build_sched_groups: got group c0000000e7d80000 with cpus:
[    0.033844] sd name: SMT span: 8-15
[    0.033847] sd name: DIE span: 0-15  <-- !!!
[    0.033850] sd name: SMT span: 8-15
[    0.033853] sd name: DIE span: 0-15
...

and the cpu mask of DIE spans all CPUs '0-15'.

Then during the rebuild of the sched domain hierarchy, this looks very
different:

...
[  181.914494] build_sched_groups: got group c000000006da0000 with cpus:
[  181.914498] build_sched_groups: got group c0000000dd830000 with cpus:
[  181.915234] sd name: SMT span: 8-15
[  181.915239] sd name: DIE span: 0-7   <-- !!!
[  181.915242] sd name: NUMA span: 0-15
...

The cpu mask of the DIE level is all the sudden '0-7', which is clearly
wrong.

So I suspect that sched_domain_mask_f mask function for the DIE level
'cpu_cpu_mask()' returns a wrong value during this rebuild.

Could be checked with this little patch-let:

@@ -6467,6 +6467,12 @@ struct sched_domain *build_sched_domain(struct
sched_domain_topology_level *tl,
        if (!sd)
                return child;

+       printk("%s: cpu: %d level: %s cpu_map: %pc tl->mask: %pc\n",
+                       __func__,
+                       cpu, tl->name,
+                       cpu_map,
+                       tl->mask(cpu));
+
        cpumask_and(sched_domain_span(sd), cpu_map, tl->mask(cpu));
        if (child) {
                sd->level = child->level + 1;


Should give you something similar like:

...
build_sched_domain: cpu: 0 level: GMC cpu_map: 0-4 tl->mask: 0
build_sched_domain: cpu: 0 level: MC cpu_map: 0-4 tl->mask: 0-1
build_sched_domain: cpu: 0 level: DIE cpu_map: 0-4 tl->mask: 0-4
build_sched_domain: cpu: 1 level: GMC cpu_map: 0-4 tl->mask: 1
build_sched_domain: cpu: 1 level: MC cpu_map: 0-4 tl->mask: 0-1
build_sched_domain: cpu: 1 level: DIE cpu_map: 0-4 tl->mask: 0-4
...

> 
> cheers
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>