Re: [PATCH 04/12] sched: Remove fixed NR_CPUS sized arrays in kernel_sched_c v2

[Mike Travis <travis@sgi.com>]

Tony Luck wrote:
> On Fri, Apr 4, 2008 at 6:11 PM, Mike Travis <travis@sgi.com> wrote:
>>  @@ -7297,6 +7287,11 @@ void __init sched_init_smp(void)
>>   #else
>>   void __init sched_init_smp(void)
>>   {
>>  +#if defined(CONFIG_NUMA)
>>  +       sched_group_nodes_bycpu = kzalloc(nr_cpu_ids * sizeof(void **),
>>  +                                                               GFP_KERNEL);
>>  +       BUG_ON(sched_group_nodes_bycpu == NULL);
>>  +#endif
>>         sched_init_granularity();
>>   }
>>   #endif /* CONFIG_SMP */
> 
> This hunk is causing problems with one of my builds (generic,
> uniprocessor). Note
> that the #else at the start of this hunk is from a #ifdef CONFIG_SMP ... so I'm
> wondering why we need #if defined(CONFIG_NUMA) inside uniprocessor code :-)
> How can you have NUMA issues with only one cpu!!!
> 
> [I'm also wondering why the config that has the compile problem has CONFIG_SMP=n
> and CONFIG_NUMA=y ... but that weirdness exposed this silliness, so
> perhaps it isn't
> all bad]
> 
> Error message is:
> kernel/sched.c: In function `sched_init_smp':
> kernel/sched.c:7994: error: `sched_group_nodes_bycpu' undeclared
> (first use in this function)
> kernel/sched.c:7994: error: (Each undeclared identifier is reported only once
> kernel/sched.c:7994: error: for each function it appears in.)
> 
> -Tony

Hi Tony,

Hmm, yes, good point.  I guess you might have it when there's a single
processor under a guest OS that's not on node 0, but I suspect there's
plenty of other problems with that scenario.

We could make CONFIG_NUMA dependent on CONFIG_SMP?  Or define
sched_group_nodes_bycpu for the non-SMP case?

[I'll have to go back to that patch and research why I added this.]

Thanks,
Mike