[dm-devel] slab: introduce the flag SLAB_MINIMIZE_WASTE

[Mikulas Patocka]

On Mon, 16 Apr 2018, Mike Snitzer wrote:

> On Mon, Apr 16 2018 at 10:37am -0400,
> Mikulas Patocka <mpatocka at redhat.com> wrote:
> 
> > 
> > 
> > On Mon, 16 Apr 2018, Mike Snitzer wrote:
> > 
> > > On Mon, Apr 16 2018 at  8:38am -0400,
> > > Vlastimil Babka <vbabka at suse.cz> wrote:
> > > 
> > > > On 04/13/2018 05:10 PM, Mike Snitzer wrote:
> > > > > On Fri, Apr 13 2018 at  5:22am -0400,
> > > > > Vlastimil Babka <vbabka at suse.cz> wrote:
> > > > >>
> > > > >> Would this perhaps be a good LSF/MM discussion topic? Mikulas, are you
> > > > >> attending, or anyone else that can vouch for your usecase?
> > > > > 
> > > > > Any further discussion on SLAB_MINIMIZE_WASTE should continue on list.
> > > > > 
> > > > > Mikulas won't be at LSF/MM.  But I included Mikulas' dm-bufio changes
> > > > > that no longer depend on this proposed SLAB_MINIMIZE_WASTE (as part of
> > > > > the 4.17 merge window).
> > > > 
> > > > Can you or Mikulas briefly summarize how the dependency is avoided, and
> > > > whether if (something like) SLAB_MINIMIZE_WASTE were implemented, the
> > > > dm-bufio code would happily switch to it, or not?
> > > 
> > > git log eeb67a0ba04df^..45354f1eb67224669a1 -- drivers/md/dm-bufio.c
> > > 
> > > But the most signficant commit relative to SLAB_MINIMIZE_WASTE is: 
> > > 359dbf19ab524652a2208a2a2cddccec2eede2ad ("dm bufio: use slab cache for 
> > > dm_buffer structure allocations")
> > > 
> > > So no, I don't see why dm-bufio would need to switch to
> > > SLAB_MINIMIZE_WASTE if it were introduced in the future.
> > 
> > Currently, the slab cache rounds up the size of the slab to the next power 
> > of two (if the size is large). And that wastes memory if that memory were 
> > to be used for deduplication tables.
> 
> You mean on an overall size of the cache level?  Or on a per-object
> level?  I can only imagine you mean the former.

Unfortunatelly, it rounds up every object. So, if you have six 640KB 
objects, it consumes 6MB.

> > Generally, the performance of the deduplication solution depends on how 
> > much data can you put to memory. If you round 640KB buffer to 1MB (this is 
> > what the slab and slub subsystem currently do), you waste a lot of memory. 
> > Deduplication indices with 640KB blocks are already used in the wild, so 
> > it can't be easily changed.
> 
> OK, seems you're suggesting a single object is rounded up.. so then this
> header is very wrong?:
> 
> commit 359dbf19ab524652a2208a2a2cddccec2eede2ad
> Author: Mikulas Patocka <mpatocka at redhat.com>
> Date:   Mon Mar 26 20:29:45 2018 +0200
> 
>     dm bufio: use slab cache for dm_buffer structure allocations
> 
>     kmalloc padded to the next power of two, using a slab cache avoids this.
> 
>     Signed-off-by: Mikulas Patocka <mpatocka at redhat.com>
>     Signed-off-by: Mike Snitzer <snitzer at redhat.com>
> 
> Please clarify further, thanks!
> Mike

Yes, using a slab cache currently doesn't avoid this rouding (it needs the 
SLAB_MINIMIZE_WASTE patch to do that).

Mikulas