Linux Documentation
 help / color / mirror / Atom feed
From: "Chen, Yu C" <yu.c.chen@intel.com>
To: Yangyu Chen <cyy@cyyself.name>
Cc: Tim Chen <tim.c.chen@linux.intel.com>,
	K Prateek Nayak <kprateek.nayak@amd.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Valentin Schneider <vschneid@redhat.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	Yangyu Chen <yangyu.chen@intel.com>,
	<linux-kernel@vger.kernel.org>, <linux-kselftest@vger.kernel.org>,
	<linux-doc@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	"Vincent Guittot" <vincent.guittot@linaro.org>
Subject: Re: [PATCH 2/4] sched/cache: Add PR_SCHED_CACHE prctl for per-mm control
Date: Wed, 22 Jul 2026 17:44:57 +0800	[thread overview]
Message-ID: <719cd113-11a8-463a-a145-59f2b7460a84@intel.com> (raw)
In-Reply-To: <tencent_4F460FBE0B41016D2247455CEE988A90D707@qq.com>

Hi Yangyu,

thanks very much for enhancing cache-aware scheduling,

On 7/22/2026 5:10 PM, Yangyu Chen wrote:
> Cache aware scheduling is currently controlled only through global
> debugfs knobs, but the right aggressiveness is workload and platform
> specific. A multi-threaded Verilator run is one example: its RSS is
> large while only a small part of it is hot, so an RSS-based footprint
> estimate should not decide whether it is aggregated; and packing its
> threads onto the SMT siblings of one LLC beats spreading them across
> LLCs on some platforms (e.g. AMD EPYC Turin) but not on others (e.g.
> EPYC Milan). Such choices cannot be made globally for the whole
> machine. Add a prctl interface to override the knobs per process
> (per mm_struct):
> 
>    prctl(PR_SCHED_CACHE, PR_SCHED_CACHE_SET, attr, value, 0);
>    prctl(PR_SCHED_CACHE, PR_SCHED_CACHE_GET, attr, &value, 0);
> 
> A single prctl command implements both directions, like
> PR_RSEQ_SLICE_EXTENSION. The attributes are a per-process enable
> (effective only while the feature is globally active), the two
> aggregation tolerances, the overaggr percentage (applied where a
> task's own migration is admitted; group level statistics span many
> processes and keep using the global value), and an inherit mask
> selecting which attributes an mm created by execve() keeps. fork()
> always inherits everything, and the mask itself lives on the
> task_struct so it survives both, which lets a numactl-like launcher
> configure a workload and exec it.
> 
> The overrides live in mm->sc_stat with -1 meaning "follow the global
> default"; GET stores the raw value through an int pointer so this
> sentinel round-trips without being mistaken for an errno.
> mm_init_sched() gains the creating task to tell fork (p != current)
> from exec (p == current) apart. A disabled mm has its preferred LLC
> invalidated at the existing invalidation points, so all group-level
> statistics self-neutralize.
> 

We are working on a version that uses prctl to turn on/off/share
among tasks, which performs similar operations to core-scheduling
based on cookies[1]. That version decouples the mm from
cache-aware scheduling so that processes, tasks, or cgroups can
tag tasks with different "cookies". We are also exploring how to
leverage schedqos (from Qais) to take advantage of these
interfaces.

Your enhancement for tuning the parameters could be applied on top
of that, I suppose.

[1] https://github.com/chen-yu-surf/linux/commits/cache_aware_prctl_v1.4/

  reply	other threads:[~2026-07-22  9:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-22  9:08 [PATCH 0/4] sched/cache: per-process control of cache aware scheduling Yangyu Chen
2026-07-22  9:09 ` [PATCH 1/4] sched/cache: Split llc_aggr_tolerance into nr and size tolerances Yangyu Chen
2026-07-22  9:10 ` [PATCH 2/4] sched/cache: Add PR_SCHED_CACHE prctl for per-mm control Yangyu Chen
2026-07-22  9:44   ` Chen, Yu C [this message]
2026-07-22 10:13   ` Chen, Yu C
2026-07-22 20:56     ` Tim Chen
2026-07-22  9:10 ` [PATCH 3/4] selftests/prctl: Add PR_SCHED_CACHE tests Yangyu Chen
2026-07-22  9:10 ` [PATCH 4/4] docs/scheduler: Document cache aware scheduling controls Yangyu Chen

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=719cd113-11a8-463a-a145-59f2b7460a84@intel.com \
    --to=yu.c.chen@intel.com \
    --cc=corbet@lwn.net \
    --cc=cyy@cyyself.name \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=skhan@linuxfoundation.org \
    --cc=tim.c.chen@linux.intel.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=yangyu.chen@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox