Re: [Patch v4 01/22] sched/cache: Introduce infrastructure for cache-aware load balancing

Chen, Yu C
2026-04-10T06:31:16Z

On 4/10/2026 7:00 AM, Peter Zijlstra wrote:
> On Thu, Apr 09, 2026 at 12:21:58PM -0700, Tim Chen wrote:
>
>>>> + get_nr_threads(p) <= 1) {
>>>
>>> And this, I just noticed this, why are we excluding tasks with one
>>> thread? The comment just states we are (doh), but utterly fails to
>>> explain why.
>>
>> The thought was that for a single thread, we will tend to place it
>> in same LLC as it was previously running with cache hot. Incurring
>> the added cost of tracking its residency in LLC is uneeded.
>
> Not sure -- the moment it gets migrated away, it will stay away. There
> is no force to pull it back, while with cache aware it will try and come
> back for a short while -- until it's build an occupancy on the new llc.
>

Besides Tim's scenario, in the original design, I thought the
beneficiary of
cache-aware scheduling was mainly multi-threaded processes, where threads
share data with each other. Single-threaded processes normally exhibit
no data sharing. This check was also introduced to prevent a single process
from concentrating excessively on one LLC. Nevertheless, we can omit this
check if the user provides hints for such single-threaded workloads, either
via prctl or other interfaces in the future.

> Anyway, if you want to do this, it needs to be a separate patch.

OK, we will move this check into a separate one.

thanks,
Chenyu