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

[Tim Chen <tim.c.chen@linux.intel.com>]

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:
> > 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.

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/ :

>> 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