From: Mikulas Patocka <mpatocka@redhat.com> To: Mike Snitzer <snitzer@redhat.com> Cc: Vlastimil Babka <vbabka@suse.cz>, Christopher Lameter <cl@linux.com>, Matthew Wilcox <willy@infradead.org>, Pekka Enberg <penberg@kernel.org>, linux-mm@kvack.org, dm-devel@redhat.com, David Rientjes <rientjes@google.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Andrew Morton <akpm@linux-foundation.org> Subject: Re: slab: introduce the flag SLAB_MINIMIZE_WASTE Date: Mon, 16 Apr 2018 10:37:21 -0400 (EDT) [thread overview] Message-ID: <alpine.LRH.2.02.1804161031300.24222@file01.intranet.prod.int.rdu2.redhat.com> (raw) In-Reply-To: <20180416142703.GA22422@redhat.com> On Mon, 16 Apr 2018, Mike Snitzer wrote: > On Mon, Apr 16 2018 at 8:38am -0400, > Vlastimil Babka <vbabka@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@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. 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. > Mike Mikulas
WARNING: multiple messages have this Message-ID (diff)
From: Mikulas Patocka <mpatocka@redhat.com> To: Mike Snitzer <snitzer@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org>, Matthew Wilcox <willy@infradead.org>, Pekka Enberg <penberg@kernel.org>, linux-mm@kvack.org, dm-devel@redhat.com, David Rientjes <rientjes@google.com>, Christopher Lameter <cl@linux.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Vlastimil Babka <vbabka@suse.cz> Subject: Re: slab: introduce the flag SLAB_MINIMIZE_WASTE Date: Mon, 16 Apr 2018 10:37:21 -0400 (EDT) [thread overview] Message-ID: <alpine.LRH.2.02.1804161031300.24222@file01.intranet.prod.int.rdu2.redhat.com> (raw) In-Reply-To: <20180416142703.GA22422@redhat.com> On Mon, 16 Apr 2018, Mike Snitzer wrote: > On Mon, Apr 16 2018 at 8:38am -0400, > Vlastimil Babka <vbabka@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@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. 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. > Mike Mikulas
next prev parent reply other threads:[~2018-04-16 14:37 UTC|newest] Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-20 17:25 [PATCH] slab: introduce the flag SLAB_MINIMIZE_WASTE Mikulas Patocka 2018-03-20 17:35 ` Matthew Wilcox 2018-03-20 17:35 ` Matthew Wilcox 2018-03-20 17:54 ` Christopher Lameter 2018-03-20 17:54 ` Christopher Lameter 2018-03-20 19:22 ` Mikulas Patocka 2018-03-20 19:22 ` Mikulas Patocka 2018-03-20 20:42 ` Christopher Lameter 2018-03-20 20:42 ` Christopher Lameter 2018-03-20 22:02 ` Mikulas Patocka 2018-03-20 22:02 ` Mikulas Patocka 2018-03-21 15:35 ` Christopher Lameter 2018-03-21 15:35 ` Christopher Lameter 2018-03-21 16:25 ` Mikulas Patocka 2018-03-21 16:25 ` Mikulas Patocka 2018-03-21 17:10 ` Matthew Wilcox 2018-03-21 17:10 ` Matthew Wilcox 2018-03-21 17:30 ` Christopher Lameter 2018-03-21 17:30 ` Christopher Lameter 2018-03-21 17:39 ` Christopher Lameter 2018-03-21 17:39 ` Christopher Lameter 2018-03-21 17:49 ` Matthew Wilcox 2018-03-21 17:49 ` Matthew Wilcox 2018-03-21 18:01 ` Christopher Lameter 2018-03-21 18:01 ` Christopher Lameter 2018-03-21 18:23 ` Mikulas Patocka 2018-03-21 18:23 ` Mikulas Patocka 2018-03-21 18:40 ` Christopher Lameter 2018-03-21 18:40 ` Christopher Lameter 2018-03-21 18:55 ` Mikulas Patocka 2018-03-21 18:55 ` Mikulas Patocka 2018-03-21 18:55 ` Matthew Wilcox 2018-03-21 18:55 ` Matthew Wilcox 2018-03-21 18:58 ` Christopher Lameter 2018-03-21 18:58 ` Christopher Lameter 2018-03-21 19:25 ` Mikulas Patocka 2018-03-21 19:25 ` Mikulas Patocka 2018-03-21 18:36 ` Mikulas Patocka 2018-03-21 18:36 ` Mikulas Patocka 2018-03-21 18:57 ` Christopher Lameter 2018-03-21 18:57 ` Christopher Lameter 2018-03-21 19:19 ` Mikulas Patocka 2018-03-21 19:19 ` Mikulas Patocka 2018-03-21 20:09 ` Christopher Lameter 2018-03-21 20:09 ` Christopher Lameter 2018-03-21 20:37 ` Mikulas Patocka 2018-03-21 20:37 ` Mikulas Patocka 2018-03-23 15:10 ` Christopher Lameter 2018-03-23 15:10 ` Christopher Lameter 2018-03-23 15:31 ` Mikulas Patocka 2018-03-23 15:31 ` Mikulas Patocka 2018-03-23 15:48 ` Christopher Lameter 2018-03-23 15:48 ` Christopher Lameter 2018-04-13 9:22 ` Vlastimil Babka 2018-04-13 9:22 ` Vlastimil Babka 2018-04-13 15:10 ` Mike Snitzer 2018-04-13 15:10 ` Mike Snitzer 2018-04-16 12:38 ` Vlastimil Babka 2018-04-16 12:38 ` Vlastimil Babka 2018-04-16 14:27 ` Mike Snitzer 2018-04-16 14:27 ` Mike Snitzer 2018-04-16 14:37 ` Mikulas Patocka [this message] 2018-04-16 14:37 ` Mikulas Patocka 2018-04-16 14:46 ` Mike Snitzer 2018-04-16 14:46 ` Mike Snitzer 2018-04-16 14:57 ` Mikulas Patocka 2018-04-16 14:57 ` Mikulas Patocka 2018-04-16 15:18 ` Christopher Lameter 2018-04-16 15:18 ` Christopher Lameter 2018-04-16 15:25 ` Mikulas Patocka 2018-04-16 15:25 ` Mikulas Patocka 2018-04-16 15:45 ` Christopher Lameter 2018-04-16 15:45 ` Christopher Lameter 2018-04-16 19:36 ` Mikulas Patocka 2018-04-16 19:36 ` Mikulas Patocka 2018-04-16 19:53 ` Vlastimil Babka 2018-04-16 21:01 ` Mikulas Patocka 2018-04-17 14:40 ` Christopher Lameter 2018-04-17 18:53 ` Mikulas Patocka 2018-04-17 18:53 ` Mikulas Patocka 2018-04-17 21:42 ` Christopher Lameter 2018-04-17 14:49 ` Christopher Lameter 2018-04-17 14:49 ` Christopher Lameter 2018-04-17 14:47 ` Christopher Lameter 2018-04-17 14:47 ` Christopher Lameter 2018-04-16 19:32 ` [PATCH RESEND] " Mikulas Patocka 2018-04-17 14:45 ` Christopher Lameter 2018-04-17 16:16 ` Vlastimil Babka 2018-04-17 16:38 ` Christopher Lameter 2018-04-17 19:09 ` Mikulas Patocka 2018-04-17 17:26 ` Mikulas Patocka 2018-04-17 19:13 ` Vlastimil Babka 2018-04-17 19:06 ` Mikulas Patocka 2018-04-17 19:06 ` Mikulas Patocka 2018-04-18 14:55 ` Christopher Lameter 2018-04-25 21:04 ` Mikulas Patocka 2018-04-25 23:24 ` Mikulas Patocka 2018-04-26 19:01 ` Christopher Lameter 2018-04-26 21:09 ` Mikulas Patocka 2018-04-27 16:41 ` Christopher Lameter 2018-04-27 19:19 ` Mikulas Patocka 2018-06-13 17:01 ` Mikulas Patocka 2018-06-13 18:16 ` Christoph Hellwig 2018-06-13 18:53 ` Mikulas Patocka 2018-04-26 18:51 ` Christopher Lameter 2018-04-16 19:38 ` Vlastimil Babka 2018-04-16 19:38 ` Vlastimil Babka 2018-04-16 21:04 ` Mikulas Patocka 2018-04-16 21:04 ` Mikulas Patocka
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=alpine.LRH.2.02.1804161031300.24222@file01.intranet.prod.int.rdu2.redhat.com \ --to=mpatocka@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=cl@linux.com \ --cc=dm-devel@redhat.com \ --cc=iamjoonsoo.kim@lge.com \ --cc=linux-mm@kvack.org \ --cc=penberg@kernel.org \ --cc=rientjes@google.com \ --cc=snitzer@redhat.com \ --cc=vbabka@suse.cz \ --cc=willy@infradead.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.