lkml.org 
[lkml]   [2005]   [Aug]   [11]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateThu, 11 Aug 2005 12:11:05 +0530
FromBharata B Rao <>
SubjectRe: [PATCH] i386 boottime for_each_cpu broken
On Thu, Aug 11, 2005 at 04:54:44AM +0000, Zwane Mwaikambo wrote:
> for_each_cpu walks through all processors in cpu_possible_map, which is 
> defined as cpu_callout_map on i386 and isn't initialised until all 
> processors have been booted. This breaks things which do for_each_cpu 
> iterations early during boot. So, define cpu_possible_map as a bitmap with 
> NR_CPUS bits populated. This was triggered by a patch i'm working on which 
> does alloc_percpu before bringing up secondary processors.

Zwane,

I don't know the context of your work here, but a couple of 
observations.

Since you populate cpu_possible_map with NR_CPUS, alloc_percpu()
would end up allocating for all NR_CPUS.  Wouldn't you have achieved
the same thing by compile time allocation ? Wouldn't this change
lead to NR_CPUS allocations from alloc_percpu() for all users ?

Now since you have separated cpu_possible_map from cpu_callout_map,
do we need to reflect cpu_possible_map with the value from
cpu_callout_map after the cpu_callout_map is initialized fully from
smp_prepare_cpus().

BTW, I am working on Kiran's dynamic percpu allocator patch and making
it cpu hotplug aware. With that, alloc_percpu would initially allocate
only for the possible cpus and would allocate for other cpus as and when
they come up.

Regards,
Bharata.
-
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/

\
 
 \ /
  Last update: 2005-08-11 08:43    [from the cache]
©2003-2008