From: Vlastimil Babka <vbabka@suse.cz>
To: dsterba@suse.cz, Christoph Hellwig <hch@infradead.org>
Cc: David Sterba <dsterba@suse.com>,
linux-btrfs@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter <cl@linux.com>,
David Rientjes <rientjes@google.com>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>
Subject: Re: [PATCH] btrfs: disable slab merging in debug build
Date: Thu, 13 Jul 2023 14:52:18 +0200 [thread overview]
Message-ID: <b8f5d4e1-12c6-ec45-abb5-6ae65ecc8bb2@suse.cz> (raw)
In-Reply-To: <20230713120303.GT30916@twin.jikos.cz>
On 7/13/23 14:03, David Sterba wrote:
> On Thu, Jul 13, 2023 at 04:21:10AM -0700, Christoph Hellwig wrote:
>> On Wed, Jul 12, 2023 at 09:17:12PM +0200, David Sterba wrote:
>> > The slab allocator newly allows to disable merging per-slab (since
>> > commit d0bf7d5759c1 ("mm/slab: introduce kmem_cache flag
>> > SLAB_NO_MERGE")). Set this for all caches in debug build so we can
>> > verify there are no leaks when module gets reloaded.
>>
>> So we're having a discussion on linux-mm wether to just disbale slab
>> merging by default, because it really is a pain. Maybe wait for that
>> to settle before adding per-subsystem hacks for what really is a slab
>> problem?
>
> Yeah I can wait with the patch. That slab merging is considered bad is
> new.
Yeah, I wouldn't say it's universally accepted. But even if we change the
default, it's just a default that distros or users might not follow, so
there's still a space for per-cache enforcement IMHO.
> I remember discussions where Linus and (maybe?) xfs guys argued
> pro/against merging of slabs, where xfs wanted not-merging and had to
> resort to hacks like empty slab constructor that would prevent it. I
> can't find the link but that's base of my reasoning to add a flag
> assuming that merging makes sense by default.
Probably this discussion?
https://lore.kernel.org/all/CA+55aFyepmdpbg9U2Pvp+aHjKmmGCrTK2ywzqfmaOTMXQasYNw@mail.gmail.com/
prev parent reply other threads:[~2023-07-13 12:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-12 19:17 [PATCH] btrfs: disable slab merging in debug build David Sterba
2023-07-13 7:38 ` Vlastimil Babka
2023-07-13 11:21 ` Christoph Hellwig
2023-07-13 12:03 ` David Sterba
2023-07-13 12:52 ` Vlastimil Babka [this message]
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=b8f5d4e1-12c6-ec45-abb5-6ae65ecc8bb2@suse.cz \
--to=vbabka@suse.cz \
--cc=42.hyeyoo@gmail.com \
--cc=cl@linux.com \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--cc=hch@infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
/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: link
Be 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.