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

On Mon, 2026-08-31 at 22:39 +0800, Chen Yu wrote:

Hi Peter,

On Sat, Aug 29, 2026 at 11:27:21AM +0200, Peter Zijlstra wrote:

quoted

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:
 

quoted

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/ (local)

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.

I also remembered in discussions with Vern, His usage scenario has processes each comprising of threads
doing different functions, like one thread responsible for database lookup, one for encryption/decryption
and one for file IO ...etc. So the threads in different processes performing similar function
has more common data and perform better when grouped together.

Also in separate discussions with Qais, he has also mentioned that
for his environment, tasks in the same process may not share data.
https://lore.kernel.org/lkml/20260219140828.a7pyzupun7lsdw34@airbuntu/ (local) :

quoted

This initial implementation treats threads within the same process as
entities that are likely to share data. During load balancing, the

This is a very aggressive assumption. From what I've seen, only few tasks truly
share data. Lumping everything in a process together is an easy way to
classify, but I think we can do better.

So this series is an attempt to address such cases where grouping
tasks by other criteria than mm makes sense.

Tim