User: Password:
Subscribe / Log in / New account

SLQB - and then there were four

SLQB - and then there were four

Posted Dec 17, 2008 9:39 UTC (Wed) by Nick (guest, #15060)
In reply to: SLQB - and then there were four by alonz
Parent article: SLQB - and then there were four

The SLAB allocator effectively has similar tunables and watermarks (number of objects in an array-cache, number of objects in l3 lists, alien caches, etc), and it performs very well in very many real world situations.

SLQB uses lists rather than arrays, so it is also more flexible to tune at runtime than SLAB. But in practice it is very difficult to adjust the sizing of these kinds of things at runtime. I've taken the dumb easy (SLAB) way out of it and periodically trim down some of the lists. That can cut back memory usage for unused slabs, and they can grow back if needed (and trim is relatively infrequent so it doesn't harm performance).

Thanks for the article, BTW. I feel like I understand the thing better myself now too :)

(Log in to post comments)

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds