On Sun, May 15, 2016 at 01:27:39PM +0200, Sven Eckelmann wrote:
On Saturday 14 May 2016 16:51:29 Linus Lüssing wrote:
Hi,
Is anyone familiar with the implications of using kmalloc() vs. kmem_cache_alloc()? Not just allocation speed, but also RAM fragmentation is something I'm currently wondering about.
Yes, it should reduce the effects of allocating differently sized objects (which can create smaller regions of memory which cannot be used anymore). But my guess is that SLAB isn't that bad because it already has some caches for differently sized memory regions.
Yes, I tested the following patchset [0] yesterday, created a few hundred clients in x86 VMs and obsevered the output of /proc/slabinfo.
* tt_global_entry uses kmalloc-node cache (objsize 192), same size for a batadv_tt_global_cache * tt_orig_list_entry uses a kmalloc-64, same size for a batadv_tt_orig_cache
(sizeof(tt-global) -> 144, sizeof(orig-entry) -> 56, sizeof(tt-common) -> 64, sizeof(tt_local) -> 80)
So indeed it looks like there might not be a difference in using one of the predefined or a custom cache fragmentation wise. And the wasted space seems to be the same (if I'm not misinterpreting the output of slabinfo).
On the other hand it seems common to use custom caches for larger amounts of frequently changing objects of the same type. Filesystems seem to use them regularly.
I think we should check if this helps by first testing it with the main TT objects. I've send an RFC patch [1]. Unfortunately, I am not aware of any nice tools to really check the size of the available, continuous memory chunks. The only thing partially interesting I know about is /proc/slabinfo which shows you the state of the available caches (including the slab page caches).
Ok, yes, that's what I had looked at yesterday, too. I'll check whether I can get some guys from Freifunk Rhein-Neckar or Freifunk Hamburg to test these patches and whether they make a difference for them.
Kind regards, Sven
[0] https://git.open-mesh.org/batman-adv.git/shortlog/refs/heads/linus/kmem-cach...