From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb0-f198.google.com (mail-yb0-f198.google.com [209.85.213.198]) by kanga.kvack.org (Postfix) with ESMTP id 6DCFF6B0003 for ; Mon, 16 Apr 2018 10:46:41 -0400 (EDT) Received: by mail-yb0-f198.google.com with SMTP id g7-v6so1157000ybd.17 for ; Mon, 16 Apr 2018 07:46:41 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com. [66.187.233.73]) by mx.google.com with ESMTPS id w47si388588qtw.69.2018.04.16.07.46.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Apr 2018 07:46:40 -0700 (PDT) Date: Mon, 16 Apr 2018 10:46:39 -0400 From: Mike Snitzer Subject: Re: slab: introduce the flag SLAB_MINIMIZE_WASTE Message-ID: <20180416144638.GA22484@redhat.com> References: <20c58a03-90a8-7e75-5fc7-856facfb6c8a@suse.cz> <20180413151019.GA5660@redhat.com> <20180416142703.GA22422@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Mikulas Patocka 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, 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. > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Snitzer Subject: Re: slab: introduce the flag SLAB_MINIMIZE_WASTE Date: Mon, 16 Apr 2018 10:46:39 -0400 Message-ID: <20180416144638.GA22484@redhat.com> References: <20c58a03-90a8-7e75-5fc7-856facfb6c8a@suse.cz> <20180413151019.GA5660@redhat.com> <20180416142703.GA22422@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Mikulas Patocka Cc: Andrew Morton , Matthew Wilcox , Pekka Enberg , linux-mm@kvack.org, dm-devel@redhat.com, David Rientjes , Christopher Lameter , Joonsoo Kim , Vlastimil Babka List-Id: dm-devel.ids 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. > 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