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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 8 Jul 2007 09:51:19 +0200 From: Ingo Molnar <mingo@...e.hu> To: Christoph Lameter <clameter@....com> Cc: linux-kernel@...r.kernel.org, linux-mm@...r.kernel.org, suresh.b.siddha@...el.com, corey.d.gough@...el.com, Pekka Enberg <penberg@...helsinki.fi>, akpm@...ux-foundation.org, Matt Mackall <mpm@...enic.com> Subject: Re: [patch 09/10] Remove the SLOB allocator for 2.6.23 (added Matt to the Cc: list) * Christoph Lameter <clameter@....com> wrote: > Maintenance of slab allocators becomes a problem as new features for > allocators are developed. The SLOB allocator in particular has been > lagging behind in many ways in the past: > > - Had no support for SLAB_DESTROY_BY_RCU for years (but no one > noticed) > > - Still has no support for slab reclaim counters. This may currently > not be necessary if one would restrict the supported configurations > for functionality relying on these. But even that has not been done. > > The only current advantage over SLUB in terms of memory savings is > through SLOBs kmalloc layout that is not power of two based like SLAB > and SLUB which allows to eliminate some memory waste. > > Through that SLOB has still a slight memory advantage over SLUB of > ~350k in for a standard server configuration. It is likely that the > savings are is smaller for real embedded configurations that have less > functionality. actually, one real advantage of the SLOB is that it is a minimal, really simple allocator. Its text and data size is so small as well. here's the size comparison: text data bss dec hex filename 10788 837 16 11641 2d79 mm/slab.o 6205 4207 124 10536 2928 mm/slub.o 1640 44 4 1688 698 mm/slob.o slab/slub have roughly the same footprint, but slob is 10% of that size. Would be a waste to throw this away. A year ago the -rt kernel defaulted to the SLOB for a few releases, and barring some initial scalability issues (which were solved in -rt) it worked pretty well on generic PCs, so i dont buy the 'it doesnt work' argument either. 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