lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 8 Dec 2007 21:29:30 +0100 From: Ingo Molnar <mingo@...e.hu> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Andrew Morton <akpm@...ux-foundation.org>, Matt Mackall <mpm@...enic.com>, "Rafael J. Wysocki" <rjw@...k.pl>, LKML <linux-kernel@...r.kernel.org>, Christoph Lameter <clameter@....com> Subject: Re: tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52, [2.6.24-rc4-git5: Reported regressions from 2.6.23] * Ingo Molnar <mingo@...e.hu> wrote: > the SLUB concept is proudly outlined in init/Kconfig: > > config SLUB > bool "SLUB (Unqueued Allocator)" > help > SLUB is a slab allocator that minimizes cache line usage > instead of managing queues of cached objects (SLAB approach). > Per cpu caching is realized using slabs of objects instead > of queues of objects. SLUB can use memory efficiently > and has enhanced diagnostics. > > but that's not true anymore - the two concepts are pretty much > equivalent, after all the "performance tuning" that went on in SLUB. > (read: 'frantically try to catch up with SLAB in benchmarks') 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists