Messages in this thread | | | Date | Tue, 6 May 2003 15:08:56 +0530 | From | Dipankar Sarma <> | Subject | Re: [PATCH] kmalloc_percpu |
| |
On Tue, May 06, 2003 at 03:04:11PM +0530, Ravikiran G Thirumalai wrote: > > 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? 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?
We can have something like that for !CONFIG_NUMA and a NUMA-aware allocator with additional dereferencing cost for CONFIG_NUMA. Hopefully gains from numa-awareness will more than offset dereferencing costs.
Thanks Dipankar - 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/
| |