Messages in this thread | | | Date | Thu, 09 Feb 2006 05:36:14 +0100 | From | Eric Dumazet <> | Subject | Re: [PATCH] percpu data: only iterate over possible CPUs |
| |
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. Its even documented in line 332 of include/linux/cpumask.h
* #ifdef CONFIG_HOTPLUG_CPU * cpu_possible_map - all NR_CPUS bits set
arch/i386/kernel/smpboot.c is doing the only sane stuff about it :
#ifdef CONFIG_HOTPLUG_CPU cpumask_t cpu_possible_map = CPU_MASK_ALL; #else cpumask_t cpu_possible_map; #endif
Some remarks :
1) These cpu_possible_map could have __read_mostly attribute. 2) cpu_possible(cpu) macro could be defined to 1 if CONFIG_HOTPLUG_CPU, or a test against NR_CPUS
#ifdef CONFIG_HOTPLUG_CPU #define cpu_possible(cpu) cpu_isset((cpu), cpu_possible_map) #else #define cpu_possible(cpu) ((unsigned)(cpu) < NR_CPUS) #endif
Eric - 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/
| |