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

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?