Re: [Patch v4 00/22] Cache aware scheduling

[Chen, Yu C]

On 4/21/2026 8:34 AM, Qais Yousef wrote:
> On 04/20/26 17:01, Chen, Yu C wrote:
> > On 4/16/2026 8:27 AM, Qais Yousef wrote:
> > > On 04/01/26 14:52, Tim Chen wrote:
> >
> > [ ... ]
> >
> > It seems to me that there are multiple use cases. In one scenario,
> > the administrator (including daemons) is responsible for tagging
> > workloads. In another, users prefer the OS to handle automatic
> > placement without any userspace involvement.
>
> How do you define this automatic placement? AFAICS you're just grouping all
> tasks of a specific process to stay within the same LLC and hitting overcommit
> issues which you're workingaround with this load balancer only based approach?
>
> I think in practice there will be many corner cases where state is not optimal
> and we'd end up with heuristics to 'balance' things out and sensitivity to
> independent changes disturbing this fragile balance causing weird regressions
> and us slowly has less flexibility to move and shuffle code (okay, maybe too
> much doom and gloom, but we've been by this in the past :)).
>
> I am not sure how many of these tests stressed the system with multiple
> critical processes running concurrently?

In the initial RFC patches, we ran multi-process tests,
where workloads were assigned by cache-aware LB to dedicated
LLCs when under-loaded. I just conducted additional
multi-process hackbench tests, and the results demonstrate
improved stabilization with cache-aware LB enabled. Thus,
I think for multi-process cases, there is no difference from
single-process cases - the tasks can be aggregated to one LLC
as long as it is under-loaded, no matter what process this
migrating task belongs to.

> By making it a userspace problem they have to figure out the right balance and
> we can focus on providing the right mechanism.

I totally agree that with the help from userspace, the task aggregation
would become more usable. The test data would speak. Once we have resolved
the issues reported by Sashiko we will evaluate the schedqos provided
interface.

thanks,
Chenyu