From: Harry Yoo <harry@kernel.org>
To: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
Cc: 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 <damien.lemoal@opensource.wdc.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Kees Cook <kees@kernel.org>
Subject: Re: [PATCH RFC 2/8] mm, slab: introduce slab_debug=N
Date: Thu, 24 Sep 2026 16:39:33 +0100 [thread overview]
Message-ID: <arVB9DuVa28Pxz-a@thinkstation> (raw)
In-Reply-To: <arUx56ee_nkxYP_f@thinkstation>
On Thu, Sep 24, 2026 at 03:48:43PM +0100, Harry Yoo wrote:
> On Wed, Sep 23, 2026 at 05:45:07PM +0200, 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.
>
> Just to clarify, the intended behavior of slab_debug=- still
> does not change, right? (the name "No-op" could be confusing here I
> guess)
>
> And My LLM flagged an issue here (that I reviewed)
>
> Implementing it as debug flag has a few side effects:
>
> - pointer hashing will be disabled unless hash_pointers=always is
> specified. [+Cc: Kees]
>
> - Disable slab merging. Since this does not affect object metadata
> layout, this could be excluded.
excluded "from SLAB_NEVER_MERGE"
Obviously it should be still part of SLAB_MERGE_SAME though.
next prev parent reply other threads:[~2026-09-24 15:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 15:45 [PATCH RFC 0/8] replace CONFIG_SLUB_TINY with a slab_tiny boot parameter Vlastimil Babka (SUSE)
2026-09-23 15:45 ` [PATCH RFC 1/8] mm, slab: refactor slab_min/max_order handling Vlastimil Babka (SUSE)
2026-09-23 15:45 ` [PATCH RFC 2/8] mm, slab: introduce slab_debug=N Vlastimil Babka (SUSE)
2026-09-24 14:48 ` Harry Yoo
2026-09-24 15:39 ` Harry Yoo [this message]
2026-09-23 15:45 ` [PATCH RFC 3/8] mm, slab: rework KMALLOC_RECLAIM handling of SLUB_TINY Vlastimil Babka (SUSE)
2026-09-23 15:45 ` [PATCH RFC 4/8] mm, slab: make SLUB_TINY handling dynamic for sizing decisions Vlastimil Babka (SUSE)
2026-09-23 15:45 ` [PATCH RFC 5/8] mm, slab: convert CONFIG_SLUB_TINY checks to kmem_cache_debug() Vlastimil Babka (SUSE)
2026-09-23 15:45 ` [PATCH RFC 6/8] mm, slab: remove remaining compile-time checks for CONFIG_SLUB_TINY Vlastimil Babka (SUSE)
2026-09-23 15:45 ` [PATCH RFC 7/8] mm, slab: add slab_tiny boot param Vlastimil Babka (SUSE)
2026-09-24 7:26 ` Vlastimil Babka (SUSE)
2026-09-23 15:45 ` [PATCH RFC 8/8] mm, slab: deprecate CONFIG_SLUB_TINY and reduce its Kconfig effects Vlastimil Babka (SUSE)
2026-09-24 15:18 ` [PATCH RFC 0/8] 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=arVB9DuVa28Pxz-a@thinkstation \
--to=harry@kernel.org \
--cc=cl@gentwo.org \
--cc=conor@kernel.org \
--cc=damien.lemoal@opensource.wdc.com \
--cc=geert@linux-m68k.org \
--cc=hao.li@linux.dev \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@kernel.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: 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.