Re: [PATCH] Avoid mask based num_possible_cpus and num_online_cpus -v5

[Rusty Russell <rusty@rustcorp.com.au>]

On Wed, 1 Feb 2012 14:01:25 -0800, Andrew Morton <akpm@linux-foundation.org> wrote:
> > Though most of the callers of these two routines are init time (with few
> > exceptions of runtime calls), it is cleaner to use variables
> > and not go through this repeated mask based calculation.
> 
> Looks good to me.

But, I wonder who's asking num_possible_cpus().  It's not a very useful
thing to know, though some arch's "know" it's contiguous, so can cheat.

Optimizing it seems particularly foolish.  We either audit and wean
everyone off who's using it incorrectly, or insist on contiguous CPU
numbers and drop the mask altogether.

> > --- a/kernel/cpu.c
> > +++ b/kernel/cpu.c
> > @@ -604,9 +604,13 @@ EXPORT_SYMBOL(cpu_all_bits);
> >  #ifdef CONFIG_INIT_ALL_POSSIBLE
> >  static DECLARE_BITMAP(cpu_possible_bits, CONFIG_NR_CPUS) __read_mostly
> >  	= CPU_BITS_ALL;
> > +unsigned int nr_possible_cpus __read_mostly = CONFIG_NR_CPUS;
> >  #else
> >  static DECLARE_BITMAP(cpu_possible_bits, CONFIG_NR_CPUS) __read_mostly;
> > +unsigned int nr_possible_cpus __read_mostly;
> >  #endif
> > +EXPORT_SYMBOL(nr_possible_cpus);
> 
> What the heck is CONFIG_INIT_ALL_POSSIBLE?
> 
> <blames Rusty>
> 
> :    1) Some archs (m32, parisc, s390) set possible_map to all 1, so we add a
> :       CONFIG_INIT_ALL_POSSIBLE for this rather than break them.
> 
> Seems strange.  Do these architectures really need to initialise
> cpu_possible_map at compile-time, when all the other architectures
> manage to do it at runtime?

IIRC playing with 3 archs boot code seemed like a recipe for disaster.
Feel free to try to fix this in -next though, and see what breaks...

Cheers,
Rusty.