On Wed, 2015-07-29 at 12:52 +0100, Ben Hutchings wrote: > > The upstream Kconfig says that SLUB is the default slab allocator > of > > choice. Where as in Debian, we choose SLAB as the default. > > SLUB developers *wanted* it to be the default. > > > My understanding is that the upstream kernel defaults are very > > orthodox, during selection ? > > As no default is explicitly specified for this choice, SLAB - being > the > first option - is the actual default. > > Looking at the in-tree defconfig files, there are: > > 230 CONFIG_SLAB=y > 12 CONFIG_SLOB=y > 1 CONFIG_SLUB=y Thanks for the info Ben. There's a nice status update on allocators at the Linux Foundation website [0] giving some nice comparison, history, stats, and status on the slab allocators. And it is recent enough as it is from 2014. I'm sure you must have seen that. In that slide deck, there's some interesting points (quoted below). While I am no expert, but the slide has varying comments on performance claims. And I'm not sure how to interpret that english: "is fast for benchmarking". Comparing performance • SLOB is slow (atomics in fastpath, global locking) • SLAB is fast for benchmarking • SLUB is fast in terms of cycles used for the fastpath but may have issues with caching. • SLUB is compensating for caching issues with an optimized fastpath that does not require interrupt disabling etc. • Cache footprints are a main factor for performance these days. Benchmarking reserves most of the cache available for the slab operations which may be misleading. [0]http://events.linuxfoundation.org/sites/events/files/slides/slaballo cators.pdf -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention."
Attachment:
signature.asc
Description: This is a digitally signed message part