From: Harry Yoo <harry@kernel.org>
To: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Hao Li <hao.li@linux.dev>, Christoph Lameter <cl@gentwo.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Conor Dooley <conor@kernel.org>,
Damien Le Moal <dlemoal@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Alexander Potapenko <glider@google.com>,
Andrey Konovalov <andreyknvl@gmail.com>,
Dmitry Vyukov <dvyukov@google.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
kasan-dev@googlegroups.com
Subject: Re: [PATCH v3 04/10] mm, slab: introduce slab_debug=N
Date: Thu, 5 Nov 2026 14:30:00 +0000 [thread overview]
Message-ID: <auyFYsbsMm8qGThW@thinkstation> (raw)
In-Reply-To: <20261105-slub_tiny_rework-v3-4-0484ce59eabb@kernel.org>
On Thu, Nov 05, 2026 at 09:43:53AM +0100, Vlastimil Babka (SUSE) wrote:
> Enabling slab_debug has the side-effect of disabling all percpu caching
> of objects (now via sheaves), which can be sometimes useful for saving
> memory for e.g. kdump kernels. To make this possible without the
> overhead (CPU or memory) of actual debugging options such as poisoning,
> introduce a No-op debug option that only forces the debugging slow paths
> and zero sheaf capacity. The new corresponding slab flag is
> SLAB_DEBUG_NOOP.
>
> This will also allow reimplementing CONFIG_SLUB_TINY as a boot-time
> option.
>
> Two details have to be considered, as suggested by Harry Yoo [1].
>
> - While SLAB_DEBUG_NOOP is part of SLAB_DEBUG_FLAGS, it should not
> prevent cache merging as it doesn't affect object metadata, and lack
> of merging would go against the memory footprint reduction. Thus
> exclude the flag from SLAB_NEVER_MERGE.
>
> - However add the flag to SLAB_MERGE_SAME, per sashiko.
>
> - SLAB_DEBUG_NOOP alone should not request disabling printk pointer
> hashing. Thus rework the call to hash_pointers_finalize() to not rely
> on the slub_debug static key state. Instead determine whether the
> global or per-cache slab_debug options include any flags that are not
> SLAB_DEBUG_NOOP. This does not change the fact that caches created
> with explicit debug flags (i.e. slub_kunit tests) later in boot have
> no effect on pointer hashing, which is determined in
> kmem_cache_init().
>
> While documenting the new N option, remove obsolete SLAB references from
> the F option description.
>
> [1] https://lore.kernel.org/all/arUx56ee_nkxYP_f@thinkstation/
> [2] https://sashiko.dev/#/patchset/20261024-slub_tiny_rework-v2-0-bf1419ab5ffd@kernel.org?part=2
>
> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
With the sashiko report to this patch fixed, this looks good to me.
Reviewed-by: Harry Yoo (Meta) <harry@kernel.org>
One nit comment:
specifying SLAB_DEBUG_FLAGS depends on CONFIG_SLUB_DEBUG, and with this
patchset there is no way to minimize slab memory usage w/o SLUB_DEBUG.
Sounds like it's time to make SLUB_DEBUG unconditional. It's enabled on
all distros listed in kconfigs [1].
I built kernels w/o SLUB_DEBUG and the difference in the kernel
binary was about 40 KiB.
[1] https://oracle.github.io/kconfigs/?config=UTS_RELEASE&config=SLUB_DEBUG
--
Cheers,
Harry / Hyeonggon
next prev parent reply other threads:[~2026-11-05 14:30 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 8:43 [PATCH v3 00/10] replace CONFIG_SLUB_TINY with a slab_tiny boot parameter Vlastimil Babka (SUSE)
2026-11-05 8:43 ` [PATCH v3 01/10] slab, kunit: pin test slabs by an extra allocation Vlastimil Babka (SUSE)
2026-11-05 12:59 ` Harry Yoo
2026-11-05 8:43 ` [PATCH v3 02/10] kasan, " Vlastimil Babka (SUSE)
2026-11-05 13:03 ` Harry Yoo
2026-11-05 13:26 ` sashiko-bot
2026-11-05 8:43 ` [PATCH v3 03/10] mm, slab: refactor slab_min/max_order handling Vlastimil Babka (SUSE)
2026-11-05 13:12 ` Harry Yoo
2026-11-05 8:43 ` [PATCH v3 04/10] mm, slab: introduce slab_debug=N Vlastimil Babka (SUSE)
2026-11-05 13:26 ` sashiko-bot
2026-11-05 14:30 ` Harry Yoo [this message]
2026-11-05 14:36 ` Vlastimil Babka (SUSE)
2026-11-05 15:02 ` Harry Yoo
2026-11-05 8:43 ` [PATCH v3 05/10] mm, slab: rework KMALLOC_RECLAIM handling of SLUB_TINY Vlastimil Babka (SUSE)
2026-11-08 17:00 ` Harry Yoo
2026-11-05 8:43 ` [PATCH v3 06/10] mm, slab: make SLUB_TINY handling dynamic for sizing decisions Vlastimil Babka (SUSE)
2026-11-08 17:58 ` Harry Yoo
2026-11-05 8:43 ` [PATCH v3 07/10] mm, slab: convert CONFIG_SLUB_TINY checks to kmem_cache_debug() Vlastimil Babka (SUSE)
2026-11-10 14:12 ` Harry Yoo
2026-11-05 8:43 ` [PATCH v3 08/10] mm, slab: remove remaining compile-time checks for CONFIG_SLUB_TINY Vlastimil Babka (SUSE)
2026-11-10 14:19 ` Harry Yoo
2026-11-05 8:43 ` [PATCH v3 09/10] mm, slab: add slab_tiny boot param Vlastimil Babka (SUSE)
2026-11-10 14:24 ` Harry Yoo
2026-11-05 8:43 ` [PATCH v3 10/10] mm, slab: deprecate CONFIG_SLUB_TINY and reduce its Kconfig effects Vlastimil Babka (SUSE)
2026-11-10 14:39 ` Harry Yoo
2026-11-10 14:46 ` [PATCH v3 00/10] replace CONFIG_SLUB_TINY with a slab_tiny boot parameter Harry Yoo
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=auyFYsbsMm8qGThW@thinkstation \
--to=harry@kernel.org \
--cc=andreyknvl@gmail.com \
--cc=cl@gentwo.org \
--cc=conor@kernel.org \
--cc=dlemoal@kernel.org \
--cc=dvyukov@google.com \
--cc=geert@linux-m68k.org \
--cc=glider@google.com \
--cc=hao.li@linux.dev \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=ryabinin.a.a@gmail.com \
--cc=vbabka@kernel.org \
--cc=vincenzo.frascino@arm.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.