Re: [POLL] SLAB : Are the 32 and 192 bytes caches really usefull on x86_64 machines ?

Alok kataria
2005-12-21T09:46:36Z

On 12/21/05, Eric Dumazet <dada1@cosmosbay.com> wrote:
> I wonder if the 32 and 192 bytes caches are worth to be declared in
> include/linux/kmalloc_sizes.h, at least on x86_64
>
> (x86_64 : PAGE_SIZE = 4096, L1_CACHE_BYTES = 64)
>
> On my machines, I can say that the 32 and 192 sizes could be avoided in favor
> in spending less cpu cycles in __find_general_cachep()
>
> Could some of you post the result of the following command on your machines :
>
> # grep "size-" /proc/slabinfo |grep -v DMA|cut -c1-40
>
> size-131072 0 0 131072
> size-65536 0 0 65536
> size-32768 2 2 32768
> size-16384 0 0 16384
> size-8192 13 13 8192
> size-4096 161 161 4096
> size-2048 40564 42976 2048
> size-1024 681 800 1024
> size-512 19792 37168 512
> size-256 81 105 256
> size-192 1218 1280 192
> size-64 31278 86907 64
> size-128 5457 10380 128
> size-32 594 784 32
>
> Thank you
>
> PS : I have no idea why the last lines (size-192, 64, 128, 32) are not ordered...

The size-32 and size-128 caches are created before any other cache, as
the array_caches (arraycache_init) and kmem_list3's structure come
from these cache.
Thus these caches are added to the cache_chain before other caches.
And s_show just walks this chain and prints info for the caches.

Before l3 was converted into a pointer (per node slabs) we could
intialize the caches in order as we knew that the arraycache_init will
always fit in the first cache.

Thanks & Regards,
Alok
>
> 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/
>