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

[Shrikanth Hegde]

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.

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.

But what tools do user space have today to make effective decisions?
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?

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?

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