In message <20030506093411.GB29352@in.ibm.com> you write:
> On Tue, May 06, 2003 at 06:03:15PM +1000, Rusty Russell wrote:
> > In message <20030506050744.GA29352@in.ibm.com> you write:
> > ..
> > Doesn't break with sparce CPU #s, but yes, it is inefficient.
> >
>
> If you don't reduce NR_CPUS with CONFIG_NR_CPUS, you waste space (32
> bit folks won't like it) and if you say change CONFIG_NR_CPUS to 2,
> and we have cpuid 4 on a 2 way you break right?
You misunderstand, I think: on *all* archs, smp_processor_id() <
NR_CPUS is an axiom. Always has been.
The generic solution involved cpu_possible(), but it's too early in
boot for that: attempts to make it a requirement have to change
numerous archs. Not that I'm against that change...
Of course, an arch can override this default allocator, and may have
more info with which to do optimal allocation.
> If we have to address these issues at all, why can't we use the
> simpler kmalloc_percpu patch which I posted in the morning and avoid
> so much complexity and arch dependency?
Because we still need the __alloc_percpu for DECLARE_PER_CPU support
in modules 8(
Hope that clarifies,
Rusty.
-- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - 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/
This archive was generated by hypermail 2b29 : Wed May 07 2003 - 22:00:29 EST