Messages in this thread | | | From | Rusty Russell <> | Subject | Re: [PATCH] kmalloc_percpu | Date | Tue, 06 May 2003 14:08:27 +1000 |
| |
In message <1052187119.983.5.camel@rth.ninka.net> you write: > On Mon, 2003-05-05 at 18:52, Andrew Morton wrote: > > Rusty Russell <rusty@rustcorp.com.au> wrote: > > > OK. It has a size restriction: PERCPU_POOL_SIZE is the maximum total > > > kmalloc_percpu + static DECLARE_PER_CPU you'll get, ever. This is the > > > main downside. It's allocated at boot. > > > > And is subject to fragmentation. > > > > Is it not possible to go allocate another N * PERCPU_POOL_SIZE from > > slab if it runs out? > > No, then you go back to things requireing multiple levels of > dereferencing.
Actually, you can; my previous patch did this. But then all CPUS have to be one continuous allocation: since modern big-SMP machines are non-uniform, so you don't want this.
http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Misc/kmalloc_percpu-orig.patch.gz
> I think the fixed size pool is perfectly reasonable.
Yes. It's a tradeoff. I think it's worth it at the moment (although I'll add a limited printk to __alloc_percpu if it fails).
Cheers, 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/
| |