All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hao Li <hao.li@linux.dev>
To: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>,
	 Harry Yoo <harry@kernel.org>
Cc: 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
Subject: Re: [PATCH RFC v2 3/8] mm, slab: rework KMALLOC_RECLAIM handling of SLUB_TINY
Date: Wed, 28 Oct 2026 19:43:14 +0800	[thread overview]
Message-ID: <auHcj2G78VkXy-Vz@fedora> (raw)
In-Reply-To: <20261024-slub_tiny_rework-v2-3-bf1419ab5ffd@kernel.org>

On Sat, Oct 24, 2026 at 09:07:25PM +0200, Vlastimil Babka (SUSE) wrote:
> One (relatively minor) aspect of CONFIG_SLUB_TINY is the assumption that
> letting reclaimable and non-reclaimable caches merge will save more
> memory, which is more important on small systems than the page allocator
> level fragmentation (where distinguishing reclaimable slabs should
> help).
> 
> For now that has been achieved by #ifdefs that result in making the
> SLAB_RECLAIM_ACCOUNT no-op and aliasing KMALLOC_RECLAIM to
> KMALLOC_NORMAL on the enum values level.
> 
> With the goal of converting CONFIG_SLUB_TINY to a boot-time decision,
> rework this so that SLAB_RECLAIM_ACCOUNT and KMALLOC_RECLAIM are
> distinctly defined always. Now, creation of kmalloc-rcl caches is
> avoided by assigning a pointer to the normal kmalloc cache on the
> kmalloc_caches array level.
> 
> To prepare disconnecting of this boot-time decision (and the evaluation
> of the need for kmalloc_no_objext) from CONFIG_SLUB_TINY, introduce a
> slub_tiny_enabled variable that's initialized to the CONFIG_SLUB_TINY
> state.
> 
> There is one minor functional change for CONFIG_SLUB_TINY=y. Since
> SLAB_RECLAIM_ACCOUNT is not 0 anymore, caches that differ only in that
> flag will stop being mergeable. If that turns out to have a noticeable
> impact on memory footprint, we can adjust the merging decisions to
> ignore SLAB_RECLAIM_ACCOUNT when slub_tiny_enabled is true.
> 
> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
>  include/linux/slab.h | 10 ----------
>  mm/slab.h            |  5 +++--
>  mm/slab_common.c     | 12 ++++++------
>  mm/slub.c            |  2 ++

[...]

> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 02dfe4351e8b..33e76a0c3084 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -835,11 +835,7 @@ EXPORT_SYMBOL(kmalloc_size_roundup);
>  #define KMALLOC_CGROUP_NAME(sz)
>  #endif
>  
> -#ifndef CONFIG_SLUB_TINY
>  #define KMALLOC_RCL_NAME(sz)	.name[KMALLOC_RECLAIM] = "kmalloc-rcl-" #sz,
> -#else
> -#define KMALLOC_RCL_NAME(sz)
> -#endif
>  
>  #ifdef CONFIG_KMALLOC_PARTITION_CACHES
>  #define __KMALLOC_PARTITION_CONCAT(a, b) a ## b
> @@ -976,7 +972,11 @@ new_kmalloc_cache(int idx, enum kmalloc_cache_type type)
>  	unsigned int aligned_size = kmalloc_info[idx].size;
>  	int aligned_idx = idx;
>  
> -	if ((KMALLOC_RECLAIM != KMALLOC_NORMAL) && (type == KMALLOC_RECLAIM)) {
> +	if (type == KMALLOC_RECLAIM) {
> +		if (slab_tiny_enabled) {
> +			kmalloc_caches[type][idx] = kmalloc_caches[KMALLOC_NORMAL][idx];
> +			return;
> +		}
>  		flags |= SLAB_RECLAIM_ACCOUNT;
>  	} else if (IS_ENABLED(CONFIG_MEMCG) && (type == KMALLOC_CGROUP)) {
>  		if (mem_cgroup_kmem_disabled()) {
> @@ -1009,7 +1009,7 @@ new_kmalloc_cache(int idx, enum kmalloc_cache_type type)
>  	 * KMALLOC_NO_OBJ_EXT cache.
>  	 */
>  	if (!mem_cgroup_kmem_disabled()) {
> -		if (type == KMALLOC_NORMAL && KMALLOC_RECLAIM != KMALLOC_NORMAL)
> +		if (type == KMALLOC_NORMAL && !slab_tiny_enabled)

(While reviewing Harry's patch [1], I happened to notice a small inconsistency
in the current code. Since these lines are being touched in this series, I
figured I'd bring it up here, even though I haven't properly started reviewing
this series yet :D)

IIUC, for both KMALLOC_NORMAL and KMALLOC_PARTITION_START + n, if gfp has
__GFP_ACCOUNT set (and without __GFP_DMA/__GFP_RECLAIMABLE), the allocation is
redirected to KMALLOC_CGROUP. This seems to mean that neither KMALLOC_NORMAL
nor KMALLOC_PARTITION_START + n actually needs an objcg slot in obj_exts.

Right now, KMALLOC_NORMAL already doesn't carry SLAB_MAY_ACCOUNT, but
KMALLOC_PARTITION_START + n still does. Given that, would it make sense to
change this line to something like:

if (type >= KMALLOC_PARTITION_START && type <= KMALLOC_PARTITION_END &&
	!slab_tiny_enabled)

[1] https://lore.kernel.org/linux-mm/20261021-memalloc-prof-dont-waste-slabobj-ext-metadata-v1-0-096800aa3330@kernel.org/

>  			flags |= SLAB_NO_MERGE;
>  		else if (!(flags & SLAB_NO_OBJ_EXT))
>  			flags |= SLAB_MAY_ACCOUNT;
> diff --git a/mm/slub.c b/mm/slub.c
> index 51daf361c601..a3ee1bdf0eb3 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -219,6 +219,8 @@ DEFINE_STATIC_KEY_MAYBE(CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT,
>  			slab_obj_ext_has_codetag_key);
>  #endif
>  
> +bool slab_tiny_enabled __read_mostly = IS_ENABLED(CONFIG_SLUB_TINY);
> +
>  /* Structure holding extra parameters for slab allocations */
>  struct slab_alloc_context {
>  	unsigned long caller_addr;
> 
> -- 
> 2.56.0
> 


  reply	other threads:[~2026-10-28 11:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-24 19:07 [PATCH RFC v2 0/8] replace CONFIG_SLUB_TINY with a slab_tiny boot parameter Vlastimil Babka (SUSE)
2026-10-24 19:07 ` [PATCH RFC v2 1/8] mm, slab: refactor slab_min/max_order handling Vlastimil Babka (SUSE)
2026-10-24 19:07 ` [PATCH RFC v2 2/8] mm, slab: introduce slab_debug=N Vlastimil Babka (SUSE)
2026-10-24 19:22   ` sashiko-bot
2026-10-24 19:07 ` [PATCH RFC v2 3/8] mm, slab: rework KMALLOC_RECLAIM handling of SLUB_TINY Vlastimil Babka (SUSE)
2026-10-28 11:43   ` Hao Li [this message]
2026-10-24 19:07 ` [PATCH RFC v2 4/8] mm, slab: make SLUB_TINY handling dynamic for sizing decisions Vlastimil Babka (SUSE)
2026-10-24 19:07 ` [PATCH RFC v2 5/8] mm, slab: convert CONFIG_SLUB_TINY checks to kmem_cache_debug() Vlastimil Babka (SUSE)
2026-10-24 19:07 ` [PATCH RFC v2 6/8] mm, slab: remove remaining compile-time checks for CONFIG_SLUB_TINY Vlastimil Babka (SUSE)
2026-10-24 19:07 ` [PATCH RFC v2 7/8] mm, slab: add slab_tiny boot param Vlastimil Babka (SUSE)
2026-10-24 19:07 ` [PATCH RFC v2 8/8] mm, slab: deprecate CONFIG_SLUB_TINY and reduce its Kconfig effects Vlastimil Babka (SUSE)
2026-10-24 19:22   ` sashiko-bot

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=auHcj2G78VkXy-Vz@fedora \
    --to=hao.li@linux.dev \
    --cc=cl@gentwo.org \
    --cc=conor@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=harry@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.