Re: [B.A.T.M.A.N.] kmalloc() vs. kmem_cache_alloc() for global TT?

[Sven Eckelmann <sven@narfation.org>]

[-- Attachment #1: Type: text/plain, Size: 2346 bytes --]

On Sunday 15 May 2016 14:41:38 Linus Lüssing wrote:
> On Sun, May 15, 2016 at 02:06:26PM +0200, Linus Lüssing wrote:
> > Ok, yes, that's what I had looked at yesterday, too.
> 
> Btw., these were the results from slabinfo I got yesterday. The
> first one before applying the patches, the second one after:
> 
> http://metameute.de/~tux/batman-adv/slablog/before/
> http://metameute.de/~tux/batman-adv/slablog/after/
> 
> The first number is the number of lines from "batctl tg", second
> one the timestamp.

Hm, looks like the the biggest difference is in kmalloc-64. So this would mean 
that the kmalloc version uses 64 byte entries for tg entries. And the 
batadv_tt_global_cache version uses 192 bytes (so it has an even larger 
overhead). The question is now - why?

My first guess was that you you are using ar71xx with MIPS_L1_CACHE_SHIFT == 
5. This would cause a cache_line_size() of 32. The tg object is 48 bytes on 
ar71xx. So it looks like you are using a different architecture [1] because 
otherwise the (cache) alignment would also be 64 bytes. Maybe you have some 
debug things enabled that cause the extra used bytes?

Extra debug information would also explain it why bridge_fdb_cache requires 
128 bytes (cache aligned) per net_bridge_fdb_entry. I would have expected that 
it is not using more than 64 bytes and is merged automatically together with 
something like kmalloc-64 (see __kmem_cache_alias for the code merging 
different kmem_caches).


Just some thoughts about the kmem_cache approach: We would only have a benefit 
by using kmem_cache when we could have a objsize which is smaller than any 
available slub/slab kmalloc-*. Otherwise slub/slab would automatically use a 
good fitting, internal kmem_cache for everything.

Right now, the size of a tg entry on my system (ar71xx mips, amd64) would have 
a raw size of 48-80 bytes. These would end up at an objsize (cache line 
aligned) of 64-96 bytes. On OpenWrt (ar71xx) it should be merged with 
kmalloc-64 and on Debian (amd64) it should be merged with kmalloc-96 (not 
tested - but maybe it is important to mention that kmalloc-96 has an objsize 
of 128 on my running system).

Kind regards,
	Sven

[1] Yes, I saw the kvm and ACPI lines after I wrote this stuff. So you are
    most likely testing on some x86 system

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]