linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Hyeonggon Yoo <42.hyeyoo@gmail.com>, David Sterba <dsterba@suse.com>
Cc: Christoph Lameter <cl@linux.com>,
	David Rientjes <rientjes@google.com>,
	Pekka Enberg <penberg@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Roman Gushchin <roman.gushchin@linux.dev>
Subject: Re: [PATCH] mm/slab: add new flag SLAB_NO_MERGE to avoid merging per slab
Date: Wed, 24 May 2023 15:53:11 +0200	[thread overview]
Message-ID: <70763661-b2a2-4bf2-f589-e0d71083f1bd@suse.cz> (raw)
In-Reply-To: <ZG4JYr14RpNQb8li@debian-BULLSEYE-live-builder-AMD64>

On 5/24/23 14:56, Hyeonggon Yoo wrote:
> On Wed, May 24, 2023 at 12:17:48PM +0200, David Sterba wrote:
>> Add a flag that allows to disable merging per slab. This can be used for
>> more fine grained control over the caches or for debugging builds where
>> separate slabs can verify that no objects leak.
>> The slab_nomerge boot option is too coarse and would need to be enabled
>> on all testing hosts. 
> 
> Hello David,
> 
> There is no users nor interface to set this flag, I guess you're going
> to use it by modifying source code, when debugging?
> 
> Does introducing new slub_debug option (i.e. slub_debug=N,pid_namespace)
> work for your use case? (there are some boot-time slub_debug options described in
> Documentation/mm/slub.rst)

Yeah, it supports globbing so it would be e.g. slub_debug=N,btrfs*
That would deal with the "too coarse" aspect slab_nomerge. As for "need to
be enabled on all testing hosts", is it more convenient to deploy a debug
kernel build on them? Might be because you do that for other reasons
already? Just want to clarify.

BTW this was proposed as RFC few months ago but not pursued:
https://lore.kernel.org/all/167396280045.539803.7540459812377220500.stgit@firesoul/

I have no big objections, just wouldn't like to see its usage proliferate
unconditionally into non-debug builds.

>> There are some other ways how to disable merging,
>> e.g. a slab constructor but this disables poisoning besides that it adds
>> additional overhead. Other flags are internal and may have other
>> semantics.
>>
>> A concrete example what motivates the flag. During 'btrfs balance' slab
>> top reported huge increase in caches like
>> 
>>   1330095 1330095 100%    0.10K  34105       39    136420K Acpi-ParseExt
>>   1734684 1734684 100%    0.14K  61953       28    247812K pid_namespace
>>   8244036 6873075  83%    0.11K 229001       36    916004K khugepaged_mm_slot
>> 
>> which was confusing and that it's because of slab merging was not the
>> first idea.  After rebooting with slab_nomerge all the caches were from
>> btrfs_ namespace as expected.
>>
>> Signed-off-by: David Sterba <dsterba@suse.com>
>> ---
>>  include/linux/slab.h | 3 +++
>>  mm/slab_common.c     | 2 +-
>>  2 files changed, 4 insertions(+), 1 deletion(-)
>> 
>> diff --git a/include/linux/slab.h b/include/linux/slab.h
> 
> Thanks,
> 



  reply	other threads:[~2023-05-24 13:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-24 10:17 [PATCH] mm/slab: add new flag SLAB_NO_MERGE to avoid merging per slab David Sterba
2023-05-24 12:56 ` Hyeonggon Yoo
2023-05-24 13:53   ` Vlastimil Babka [this message]
2023-05-25 12:05     ` David Sterba
2023-05-25 11:59   ` David Sterba

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=70763661-b2a2-4bf2-f589-e0d71083f1bd@suse.cz \
    --to=vbabka@suse.cz \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=dsterba@suse.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).