On Mon, 16 Apr 2018, Mike Snitzer wrote:
> On Mon, Apr 16 2018 at 10:37am -0400,
> Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote:
>
> >
> >
> > On Mon, 16 Apr 2018, Mike Snitzer wrote:
> >
> > > On Mon, Apr 16 2018 at 8:38am -0400,
> > > Vlastimil Babka <vbabka@xxxxxxx> wrote:
> > >
> > > > On 04/13/2018 05:10 PM, Mike Snitzer wrote:
> > > > > On Fri, Apr 13 2018 at 5:22am -0400,
> > > > > Vlastimil Babka <vbabka@xxxxxxx> 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@xxxxxxxxxx>
> 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@xxxxxxxxxx>
> Signed-off-by: Mike Snitzer <snitzer@xxxxxxxxxx>
>
> 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
