Re: [PATCH] percpu data: only iterate over possible CPUs

From: Andrew Morton
Date: Wed Feb 08 2006 - 23:44:23 EST

Eric Dumazet <dada1@xxxxxxxxxxxxx> wrote:
> Andrew Morton a écrit :
> > Andrew Morton <akpm@xxxxxxxx> wrote:
> >> Users of __GENERIC_PER_CPU definitely need cpu_possible_map to be initialised
> >> by the time setup_per_cpu_areas() is called,
> >
> > err, they'll need it once Eric's
> > dont-waste-percpu-memory-on-not-possible-CPUs patch is merged..
> >
> >> so I think it makes sense to
> >> say "thou shalt initialise cpu_possible_map in setup_arch()".
> >>
> >> I guess Xen isn't doing that. Can it be made to?
> >
> > Lame fix: cpu_possible_map = (1<<NR_CPUS)-1 in setup_arch().
> I dont understand why this HOTPLUG stuff is problematic for Xen (or other
> arch) : If CONFIG_HOTPLUG_CPU is configured, then the map should be preset to

Presumably not all architectures are doing that. And some of the problems
we've had are with CONFIG_HOTPLUG_CPU=n.

> Its even documented in line 332 of include/linux/cpumask.h
> * cpu_possible_map - all NR_CPUS bits set

That seems a quite bad idea. If we know which CPUs are possible we should
populate cpu_possible_map correctly, whether or not CONFIG_HOTPLUG_CPU is
set. Setting all the bits like that wastes memory and wastes CPU cycles.


That comment came from the tender pinkies of pj@xxxxxxx, although I suspect
it was just a transliteration of then-current practice.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at