Messages in this thread | | | Date | Thu, 9 Feb 2006 10:08:09 -0600 | From | Nathan Lynch <> | Subject | Re: [PATCH] percpu data: only iterate over possible CPUs |
| |
Andrew Morton wrote: > Eric Dumazet <dada1@cosmosbay.com> wrote: > > > > Andrew Morton a écrit : > > > Andrew Morton <akpm@osdl.org> 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.
powerpc/ppc64, for instance, determines the number of possible cpus from information exported by firmware (and I'm mystified as to why other platforms don't do this). So it's typical to have a kernel an a pSeries partition with NR_CPUS=128, but cpu_possible_map = 0xff.
> > 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.
Yes, that comment is wrong or outdated.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |