Richard Kennedy <richard@xxxxxxxxxxxxxxx> writes: > This patch increases the range of slab sizes available to kmalloc, adding > slabs half way between the existing power of two sized ones, so allowing slightly > more efficient use of memory. > Most of the new slabs already exist as kmem_cache slabs so only the 1.5k,3k & 6k > are entirely new. I'm not sure what order slab/slub use by default these days, but for order 0 none of your new sizes sound like a winner: 4K / 1.5 = 2 = 4K / 2K 4K / 3K = 1 = 4K / 4K 8K / 6K = 1 = 8K / 8K I think you need better data that it actually saves memory with some reproducible workloads. Revisiting the sizes is a good idea -- the original Bonwick slab paper explicitely recommended against power of twos -- but I think it needs a more data driven process to actually select better ones than what you used. Most likely the best fits are different between 32bit and 64bit and also will change occasionally as kernel data structures grow (or rarely shrink) In fact I suspect it would be an interesting option for feedback control for embedded kernels - measure workload, reboot/recompile with slab fitting the workload well. So I think before trying any of this you need a good slab profiler and a good set of workloads. -Andi -- ak@xxxxxxxxxxxxxxx -- Speaking for myself only -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>