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 Wed, 2026-09-09 at 18:27 +0530, Shrikanth Hegde wrote:
> Hi Tim/Peter.
> 
> I have been trying to catch up. I still have to read
> and might have missed some conversation details. So please
> bear with me for silly questions.

Thanks for taking a look.  You questions are helpful for
providing the context of why this series was proposed.

> 
> On 8/29/26 3:59 AM, Tim Chen wrote:
> > Hi all,
> > 
> > Cache aware scheduling today groups tasks by their mm: the LLC aggregation
> > target lives in mm_struct, so the address space is the unit of grouping.
> > That works, but in some scenarios that is too coarse and too eager, and the
> > only knob we have over it is a single system-wide debugfs switch.
> > 
> > It's too coarse because plenty of workloads share data across cooperating
> > *processes* rather than threads - a database with a process per connection,
> > a browser with a renderer per site, a server and its worker helpers. They
> > pass data through shm or pipes and would love to be pulled onto the same
> > LLC, but they never share an mm, so today they can't be. And it's too eager
> > in the other direction: a process whose threads don't actually share
> > anything gets aggregated anyway, just because they happen to sit in one
> > address space.
> > 
> > So the core idea of this series is simple: allow other groupings than
> > the mm, make the grouping an object in its own right, and let user space
> > say "put these tasks together" explicitly.
> 
> So, As you said, this is effectively asking user to make the decision.

By default, tasks are grouped by process and that make sense in many cases.
But sometimes the users have information about task characteristics that they wish to group
tasks in other ways. 

In our discussions with Vern Hao from Tencent, they have multiple processes
in their workload, where some tasks in a process is responsible for
database access, some for encryption, and some dealing with disk access.
Those tasks across processes with similar function share more data than
tasks in a process for their applications.  

Another scenario is grouping processes with shared memory together.

> 
> But what tools do user space have today to make effective decisions?

As in the example above, this is for users who know about their workload
characteristics and wish to group their tasks in other way than the default
process grouping.

Also if people identify via perf c2c that tasks  

> Application changes could turn out to be tricky to do and how an
> application developer will know whether to group them together or not?
> What's guidance there?

No changes is required on application. An admin or a separate daemon
can use prctl to group tasks together by sepcifying the pids pair of tasks
to be grouped. Please see the PR_SCHED_CACHE_SHARE_FROM operation in
patch 7 of the documentation.

> 
> Can the grouping be done post the application started running?
> Like any option that says these pid's are to be bundled into one group?

Yes.

> 
> I remember you guys discussed about cgroup and decided it is not a good option.
> That argument is still holds?

I think there is no strong case to support that tasks sharing
data necessarily belong in a cgroup. Using cgroup wouldn't cover all the use cases
we want. With the proposed prctl based interface in this series,
the administrator can easily group the processes in a cgroup together
if that makes sense. We also would rather not disturb the cgroup
interface unnecessarily.

Tim