Messages in this thread | | | Date | Sat, 13 Oct 2012 09:44:01 -0300 | Subject | Re: [Q] Default SLAB allocator | From | Ezequiel Garcia <> |
| |
Hi David,
On Sat, Oct 13, 2012 at 6:54 AM, David Rientjes <rientjes@google.com> wrote: > On Fri, 12 Oct 2012, Ezequiel Garcia wrote: > >> >> SLUB is a non-starter for us and incurs a >10% performance degradation in >> >> netperf TCP_RR. >> > >> >> Where are you seeing that? >> > > In my benchmarking results. > >> Notice that many defconfigs are for embedded devices, >> and many of them say "use SLAB"; I wonder if that's right. >> > > If a device doesn't require the smallest memory footprint possible (SLOB) > then SLAB is the right choice when there's a limited amount of memory; > SLUB requires higher order pages for the best performance (on my desktop > system running with CONFIG_SLUB, over 50% of the slab caches default to be > high order). >
But SLAB suffers from a lot more internal fragmentation than SLUB, which I guess is a known fact. So memory-constrained devices would waste more memory by using SLAB. I must admit a didn't look at page order (but I will now).
>> Is there any intention to replace SLAB by SLUB? > > There may be an intent, but it'll be nacked as long as there's a > performance degradation. > >> In that case it could make sense to change defconfigs, although >> it wouldn't be based on any actual tests. >> > > Um, you can't just go changing defconfigs without doing some due diligence > in ensuring it won't be deterimental for those users.
Yeah, it would be very interesting to compare SLABs on at least some of those platforms.
Ezequiel
| |