Re: Cache-aware scheduling does not work well with amd big/little cores

["Chen, Yu C" <yu.c.chen@intel.com>]

Hi,

On 8/31/2026 9:53 AM, Mario Limonciello wrote:
> Add a few others who have worked on CAS.
> 
> On 8/29/26 10:42, Klaus Kusche wrote:
>>
>> Hello,
>>
>> I'm running linux on an AMD Ryzen HX 370.
>> I use Gentoo and compile a lot of things (including the kernel)
>> with Clang using full LTO, which results in a single LTO process
>> running for minutes on an otherwise idle processor.
>>
>> Before Cache-aware scheduling was introduced,
>> AMD's pstate driver informed the scheduler about big and little cores,
>> and the scheduler always moved those LTO processes to a big/fast core.
>>
>> Now, the cache-aware scheduling takes precedence over big/little
>> scheduling: All big cores form one L3 cache domain,
>> and all little cores form the other L3 cache domain.
>>
>> When a process is started on a little core (and LTO is in most cases),
>> it will no longer be moved to a big core,
>> even if it runs for minutes and all big cores are idle.
>>
>> In case of LTO this hurts twice and badly
>> (slows down LTO not just noticeably, but dramatically:
>> In total, any compilation with LTO-linking takes much longer
>> compared to earlier kernels without cache-aware scheduling):
>>
>> * The little cores run slower (3.3 GHz instead of 5.1 GHz).
>>
>> * LTO linking is very cache intensive,
>> and the L3 cache of the little cores is only half the size (8 MB)
>> of the L3 cache of the big cores (16 MB).
>>
>>
>> So if a big core is idling, and a process on a little core
>> is long-running, big/little scheduling should overrule
>> cache-aware scheduling and move that process to a big core,
>> even if this moves the process to another cache domain.
>>
>> Greetings
>>
> 
> Not so sure if it would help this case but I will note there is a 
> debugfs knob you might be able to use called aggr_tolerance (it was 
> introduced in c1e7fe5e75ed11fa85368e5a186472afd3858f3a if you want to 
> read more about it's background).

Thanks Mario and Kusche for bringing this issue up. Yes, we can tune Cache
Aware scheduling via debugfs or even turn it off. The issue in current code
is that the cache aware scheduling overwrites the strategy of asymmetric 
scheduling,
and Ricardo also found this issue previous and there is a patch to address
that, by honoring CPU capacity during cache aware scheduling, for the 
**misfit**
task. It would be helpful to see if this patch makes things better:
https://lore.kernel.org/lkml/20260825174112.2580942-1-tim.c.chen@linux.intel.com/

thanks,
Chenyu