SLQB - and then there were four

Posted Dec 16, 2008 21:26 UTC (Tue) by alonz (subscriber, #815)
Parent article: SLQB - and then there were four

I wonder how well this algorithm will do in real life, considering the number of tunable watermarks it needs (size of freelist, size of rlist, size of remote_free, …).

Will it be self-tuning? Even if yes, will whatever heuristics are used for this tuning stand up to dynamic situations?

SLQB - and then there were four

Posted Dec 17, 2008 9:39 UTC (Wed) by Nick (guest, #15060) [Link]

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 :)