From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb0-f199.google.com (mail-yb0-f199.google.com [209.85.213.199]) by kanga.kvack.org (Postfix) with ESMTP id 5083A6B0007 for ; Mon, 16 Apr 2018 10:57:52 -0400 (EDT) Received: by mail-yb0-f199.google.com with SMTP id h184-v6so10171455ybg.16 for ; Mon, 16 Apr 2018 07:57:52 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com. [66.187.233.73]) by mx.google.com with ESMTPS id 15si17332520qkp.330.2018.04.16.07.57.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Apr 2018 07:57:51 -0700 (PDT) Date: Mon, 16 Apr 2018 10:57:45 -0400 (EDT) From: Mikulas Patocka Subject: Re: slab: introduce the flag SLAB_MINIMIZE_WASTE In-Reply-To: <20180416144638.GA22484@redhat.com> Message-ID: References: <20c58a03-90a8-7e75-5fc7-856facfb6c8a@suse.cz> <20180413151019.GA5660@redhat.com> <20180416142703.GA22422@redhat.com> <20180416144638.GA22484@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Mike Snitzer Cc: Vlastimil Babka , Christopher Lameter , Matthew Wilcox , Pekka Enberg , linux-mm@kvack.org, dm-devel@redhat.com, David Rientjes , Joonsoo Kim , Andrew Morton On Mon, 16 Apr 2018, Mike Snitzer wrote: > On Mon, Apr 16 2018 at 10:37am -0400, > Mikulas Patocka wrote: > > > > > > > On Mon, 16 Apr 2018, Mike Snitzer wrote: > > > > > On Mon, Apr 16 2018 at 8:38am -0400, > > > Vlastimil Babka wrote: > > > > > > > On 04/13/2018 05:10 PM, Mike Snitzer wrote: > > > > > On Fri, Apr 13 2018 at 5:22am -0400, > > > > > Vlastimil Babka 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 > 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 > Signed-off-by: Mike Snitzer > > 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