Re: [RFC PATCH 0/7] sched/cache: Per-task control of cache aware scheduling via prctl

[Chen Yu <chen.yu@linux.dev>]

Hi Peter,

On Sat, Aug 29, 2026 at 11:27:21AM +0200, Peter Zijlstra wrote:
> Subject: Re: [RFC PATCH 0/7] sched/cache: Per-task control of cache aware
>  scheduling via prctl
> 
> On Fri, Aug 28, 2026 at 03:29:07PM -0700, Tim Chen wrote:
>  
> > Feedbacks very welcome, especially on the interface shape (prctl vs. a QoS
> > attribute), the kernel-owned-cookie choice, and whether the always/advise/
> > never policy composition is the right model.
> 
> Who would be using this -- what workload prompted you do do this etc.
>

One motivation is that some cloud users would like finer-grained control over
cache‑aware scheduling. Vern Hao from Tencent previously asked about this:

https://lore.kernel.org/all/7d5bb7c4-abc5-470e-84fe-72a3b1d3a2f4@gmail.com/

and mentioned that, in their production environment, threads within the same
process do not always share data. On the other hand, it is possible that within
one process there are two thread groups, A and B. Threads in group A share data
with each other, while threads in group B do not. Typically, in Vern's environment,
group A and group B are cgroups. Group A usually runs memory‑intensive workloads, such
as KV‑cache related ones, and such workloads have intensive data sharing among themselves,
so they would like to enable cache‑aware scheduling separately. Furthermore, since group A
is memory‑intensive, the default cache‑aware scheduling threshold might reject aggregation
because group A's memory footprint is high. As a result, group A has a requirement to turn the
threshold parameter separately.

thanks,
Chenyu