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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
