Eric Dumazet <[email protected]> wrote:
>
> Andrew Morton a écrit :
> > Andrew Morton <[email protected]> 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
> CPU_MASK_ALL.
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
>
> * #ifdef CONFIG_HOTPLUG_CPU
> * 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.
<greps>
That comment came from the tender pinkies of [email protected], 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
