Messages in this thread | | | Date | Wed, 04 Jan 2006 12:41:59 +0100 | From | Eric Dumazet <> | Subject | Re: [PATCH] Shrinks sizeof(files_struct) and better layout |
| |
Andi Kleen a écrit : > > Total data of all objects together. That's because caches always get their > own pages and cannot share them with other caches.
OK for this part.
> The overhead of the kmem_cache_t by itself is negligible.
This seems a common misconception among kernel devs (even the best ones Andi :) )
On SMP (and/or NUMA) machines : overhead of kmem_cache_t is *big*
See enable_cpucache in mm/slab.c for 'limit' determination :
if (cachep->objsize > 131072) limit = 1; else if (cachep->objsize > PAGE_SIZE) limit = 8; else if (cachep->objsize > 1024) limit = 24; else if (cachep->objsize > 256) limit = 54; else limit = 120;
On a 64 bits machines, 120*sizeof(void*) = 120*8 = 960
So for small objects (<= 256 bytes), you end with a sizeof(array_cache) = 1024 bytes per cpu
If 16 CPUS : 16*1024 = 16 Kbytes + all other kmem_cache structures : (If you have a lot of Memory Nodes, then it can be *very* big too).
If you know that no more than 100 objects are used in 99% of setups, then a dedicated cache is overkill, even locking 100 pages because of extreme fragmentation is better.
Probability that a *lot* of tasks are created at once and killed at once is close to 0 during a machine lifetime.
Maybe we can introduce an ultra basic memory allocator for such objects (without CPU caches, node caches), so that the memory overhead is small. Hitting a spinlock at thread creation/deletion time is not that time critical.
Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |