All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pedro Falcato <pfalcato@suse.de>
To: "Harry Yoo (Oracle)" <harry@kernel.org>
Cc: Vlastimil Babka <vbabka@kernel.org>,
	 Andrew Morton <akpm@linux-foundation.org>,
	Hao Li <hao.li@linux.dev>, Christoph Lameter <cl@gentwo.org>,
	 David Rientjes <rientjes@google.com>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	linux-mm@kvack.org,  linux-kernel@vger.kernel.org,
	Suren Baghdasaryan <surenb@google.com>,
	 "Liam R. Howlett" <liam@infradead.org>
Subject: Re: [PATCH RFC 0/8] mm/slab: enable runtime sheaves tuning
Date: Mon, 18 May 2026 13:52:34 +0200	[thread overview]
Message-ID: <agr8Nzr8rnDBTuVX@pedro-suse> (raw)
In-Reply-To: <20260516-sheaves-tuning-v1-0-221aa3e1d829@kernel.org>

On Sat, May 16, 2026 at 01:24:24AM +0900, Harry Yoo (Oracle) wrote:
> Background
> ==========
> 
> Sheaves were introduced in v6.18, and starting from v7.0, they are
> enabled for all slab caches (except for kmem_cache{,_node}). In the
> pre-sheaves era, there was a cpu_partial parameter to tune the number
> of objects cached per CPU. However, sheaves don't have an equivalent
> and the sheaf capacity is determined in the kernel code.

What semantic do you need from this?

> 
> The goal is to allow tuning sheaves at runtime by the next LTS.
> 
> Overview
> ========
> 
> This patchset does two main things:
> 
>   1. Make the sheaf_capacity sysfs attribute writable so that the number
>      of objects cached per CPU can be changed at runtime, and
> 
>   2. Expose MAX_FULL_SHEAVES and MAX_EMPTY_SHEAVES as sysfs attributes
>      rather than constants, so that users can tune them.
> 
> Measuring the performance impact of these tunables is TBD.
> 
> Roughly, the sequence to change sheaf_capacity is as follows:
> 
>   1. Disable sheaves. Make all online CPUs replace their main sheaves
>      with the bootstrap sheaf under local_lock and wait for completion.

This is extremely destabilizing performance-wise, were I to guess.

> 
>   2. Wait for all in-flight RCU callbacks to be processed.

and this too.

>   
>   3. Flush and free all existing sheaves.
> 
>   4. Re-enable sheaves with a new capacity.
> 
> Challenges
> ==========
> 
> 1. Allocations and frees can happen concurrently at any point between
>    these steps, and we cannot introduce heavyweight synchronization
>    mechanisms on the fastpath.
> 
> 2. Currently, cache_has_sheaves() checks whether a cache has sheaves.
>    This works now because sheaves cannot be enabled or disabled once
>    the cache is created.
> 
>    The question "Does this cache has sheaves?" should be split into
>    "Does this cache support sheaves?" and "Does this CPU actually has
>     sheaves enabled right now?".
> 
> 3. Once the sheaf capacity update is complete, no sheaf with stale
>    capacity must remain.

Why? I don't see a huge problem with having multiple sheaves with different
capacities, as long as you adequately, opportunistically kill the sheaves
if they don't have the desired size (say, once a sheaf is fully empty).

-- 
Pedro


  parent reply	other threads:[~2026-05-18 11:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-15 16:24 [PATCH RFC 0/8] mm/slab: enable runtime sheaves tuning Harry Yoo (Oracle)
2026-05-15 16:24 ` [PATCH RFC 1/8] mm/slab: do not store cache pointer in struct slab_sheaf Harry Yoo (Oracle)
2026-05-19  4:08   ` Hao Li
2026-05-15 16:24 ` [PATCH RFC 2/8] mm/slab: change sheaf_capacity type to unsigned short Harry Yoo (Oracle)
2026-05-15 16:24 ` [PATCH RFC 3/8] mm/slab: track capacity per sheaf Harry Yoo (Oracle)
2026-05-15 16:24 ` [PATCH RFC 4/8] mm/slab: allow bootstrap_cache_sheaves() to fail Harry Yoo (Oracle)
2026-05-15 16:24 ` [PATCH RFC 5/8] mm/slab: rework cache_has_sheaves() to check immutable properties only Harry Yoo (Oracle)
2026-05-15 16:24 ` [PATCH RFC 6/8] mm/slab: allow changing sheaf_capacity at runtime Harry Yoo (Oracle)
2026-05-17  8:30   ` Yeoreum Yun
2026-05-18  6:53     ` Harry Yoo (Oracle)
2026-05-15 16:24 ` [PATCH RFC 7/8] mm/slab: add pcs->lock lockdep assert when accessing the barn Harry Yoo (Oracle)
2026-05-15 16:24 ` [PATCH RFC 8/8] mm/slab: allow changing max_{full,empty}_sheaves at runtime Harry Yoo (Oracle)
2026-05-18 11:52 ` Pedro Falcato [this message]
2026-05-20  4:35   ` [PATCH RFC 0/8] mm/slab: enable runtime sheaves tuning Harry Yoo
2026-06-09 12:52     ` Vlastimil Babka (SUSE)
2026-06-09 13:54       ` 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=agr8Nzr8rnDBTuVX@pedro-suse \
    --to=pfalcato@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=cl@gentwo.org \
    --cc=hao.li@linux.dev \
    --cc=harry@kernel.org \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=surenb@google.com \
    --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.