* Ingo Molnar <mingo@elte.hu> wrote:just to hammer this point home - and while Christoph Lameter isnt online currently to defend SLUB, this issue did come up and i guess there must be other MM hackers that are advocates of SLUB. (otherwise this code couldnt be upstream) I find SLUB a fantastically confusing concept, and that starts at the name. "Unqueued" it says. Lets take a look at the actual code: mm/slub.c: static void __always_inline *slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, void *addr) { ... local_irq_save(flags); c = get_cpu_slab(s, smp_processor_id()); ... else { object = c->freelist; c->freelist = object[c->offset]; } local_irq_restore(flags); so it has a "free list", which is clearly per cpu. Hang on! Isnt that actually a per CPU queue? Which SLUB has not, we are told? The "U" in SLUB. How on earth can an allocator in 2007 claim to have no queuing (which is in essence caching)? Am i on crack with this? Did i miss something really obvious? Ingo --
| Avi Kivity | [PATCH 09/58] KVM: MMU: Respect nonpae pagetable quadrant when zapping ptes |
| Andrew Morton | 2.6.25-rc2-mm1 |
| James Morris | Re: LSM conversion to static interface |
| Eric W. Biederman | Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu |
git: | |
| David Miller | Re: 2.6.25-rc8: FTP transfer errors |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [GIT *] Solos PCI ADSL card update |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
