On (09/03/15 12:29), Jesper Dangaard Brouer wrote:
[..]
> I'm buying into the problem of variable object lifetime sharing the
> same slub.
> 
> With the SLAB bulk free API I'm introducing, we can speedup slub
> slowpath, by free several objects with a single cmpxchg_double, BUT
> these objects need to belong to the same page.
>  Thus, as Dave describe with merging, other users of the same size
> objects might end up holding onto objects scattered across several
> pages, which gives the bulk free less opportunities.
> 
> That would be a technical argument for introducing a SLAB_NO_MERGE flag
> per slab.  But I want to do some measurement before making any
> decision. And it might be hard to show for my use-case of SKB free,
> because SKB allocs will likely be dominating 256 bytes slab anyhow.

Out of curiosity, I did some quite simple-minded
"slab_nomerge = 0" vs. "slab_nomerge = 1" tests today on my old
x86_64 box (4gigs of RAM, ext4, 4.2.0-next-20150903):

 - git clone https://github.com/git/git; make -j8; package (archlinux);
 cleanup;
 - create a container; untar gcc-5-20150901.tar.bz2; make -j6; package;
 cleanup;


I modified /proc/slabinfo to show a total `unused` space size, accounted
in cache_show() (reset in slab_start()):

  __unused_objs_sz += (sinfo.num_objs - sinfo.active_objs) * s->size;

and captured that value every second
	tail -1 /proc/slabinfo >> slab_unused


FWIW, files with the numbers attached (+ gnuplot graph). Those numbers are
not really representative, but well, they are what they are -- on my small
x86_64 box with very limited resources and under pretty general tests
"slab_nomerge = 1" shows better numbers. (hm... can embedded benefit from
disabling merging?). I think (as Dave Chinner said), preventing active and
passive slabs merging does not sound so crazy. Just my 2 cents.

	-ss