linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.com>
To: Christoph Lameter <cl@linux.com>,
	David Rientjes <rientjes@google.com>,
	Pekka Enberg <penberg@kernel.org>,
	Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Hyeonggon Yoo <42.hyeyoo@gmail.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Roman Gushchin <roman.gushchin@linux.dev>,
	David Sterba <dsterba@suse.com>
Subject: [PATCH] mm/slab: add new flag SLAB_NO_MERGE to avoid merging per slab
Date: Wed, 24 May 2023 12:17:48 +0200	[thread overview]
Message-ID: <20230524101748.30714-1-dsterba@suse.com> (raw)

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. 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
index 6b3e155b70bf..06b94dfbce65 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -106,6 +106,9 @@
 /* Avoid kmemleak tracing */
 #define SLAB_NOLEAKTRACE	((slab_flags_t __force)0x00800000U)
 
+/* Don't merge slab */
+#define SLAB_NO_MERGE		((slab_flags_t __force)0x01000000U)
+
 /* Fault injection mark */
 #ifdef CONFIG_FAILSLAB
 # define SLAB_FAILSLAB		((slab_flags_t __force)0x02000000U)
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 607249785c07..0e0a617eae7d 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -47,7 +47,7 @@ static DECLARE_WORK(slab_caches_to_rcu_destroy_work,
  */
 #define SLAB_NEVER_MERGE (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER | \
 		SLAB_TRACE | SLAB_TYPESAFE_BY_RCU | SLAB_NOLEAKTRACE | \
-		SLAB_FAILSLAB | kasan_never_merge())
+		SLAB_FAILSLAB | SLAB_NO_MERGE | kasan_never_merge())
 
 #define SLAB_MERGE_SAME (SLAB_RECLAIM_ACCOUNT | SLAB_CACHE_DMA | \
 			 SLAB_CACHE_DMA32 | SLAB_ACCOUNT)
-- 
2.40.0



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

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-24 10:17 David Sterba [this message]
2023-05-24 12:56 ` [PATCH] mm/slab: add new flag SLAB_NO_MERGE to avoid merging per slab Hyeonggon Yoo
2023-05-24 13:53   ` Vlastimil Babka
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=20230524101748.30714-1-dsterba@suse.com \
    --to=dsterba@suse.com \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.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 \
    --cc=vbabka@suse.cz \
    /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).