From: Klaus Kusche <klaus.kusche@computerix.info>
To: "Chen, Yu C" <yu.c.chen@intel.com>,
Tim Chen <tim.c.chen@linux.intel.com>,
Mario Limonciello <mario.limonciello@amd.com>
Cc: "Badole, Vishal" <Vishal.Badole@amd.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<x86@kernel.org>,
platform-driver-x86@vger.kernel.org,
K Prateek Nayak <KPrateek.Nayak@amd.com>,
ricardo.neri@intel.com
Subject: Re: Cache-aware scheduling does not work well with amd big/little cores
Date: Mon, 14 Sep 2026 12:27:53 +0200 [thread overview]
Message-ID: <6b173ff1-6fde-401d-a4a8-6fa8bbe3287c@computerix.info> (raw)
In-Reply-To: <2fe2c681-b748-41fa-8b56-1169c86cefbc@intel.com>
I did some very quick tests.
1.) /sys/kernel/sched/debug/domains/* does not exist on my system,
not even with debug_fs on.
/sys/kernel/debug/x86/sched_itmt_enabled is "Y",
/sys/kernel/debug/x86/sched_core_priority looks good
(big cores have values almost twice as high as small cores)
2.) The situation with 7.2.5 which seems to include
https://lore.kernel.org/lkml/20260825174112.2580942-1-tim.c.chen@linux.intel.com/
is almost unchanged: Without cache aware scheduling,
my build jobs run faster (wallclock time):
Just 6:16 compared to 6:19 for my kernel build with full LTO,
but 4:50 compared to 5:20 (???) for my python uv build
(the python uv build seems to be a very interesting test case?)
However, with cache sched enabled, in spite of the longer
wallclock time, cpu seconds are sometimes a little bit lower.
3.) https://lore.kernel.org/lkml/20260810033742.1688718-1-yu.c.chen@intel.com/
seems to make things much worse:
Kernel builds had the LTO step and the CC compressed step
placed on little cores for significant amounts of time,
resulting in total build times above 8 minutes.
Same impression by watching the bar graph for individual cores
for the uv build.
Prof. Dr. Klaus Kusche
Privat: Söllmnitz 32 d, D-07554 Gera/Söllmnitz
036695/859909 klaus.kusche@computerix.info https://www.computerix.info
Dienstlich: DHGE Gera, Weg der Freundschaft 4, D-07546 Gera
klaus.kusche@dhge.de https://www.dhge.de
On 10/09/2026 03:29, Chen, Yu C wrote:
> On 9/10/2026 3:51 AM, Tim Chen wrote:
>> On Wed, 2026-09-09 at 08:19 -0500, Mario Limonciello wrote:
>>>
>>> On 9/9/26 03:59, Klaus Kusche wrote:
>>>>
>>>> Hello,
>>>>
>>>> On 08/09/2026 23:54, Tim Chen wrote:
>>>>>> I did some quick testing (no perfect benchmark environment,
>>>>>> just checking runtime and CPU consumption with "time").
>>>>>>
>>>>>> I timed a kernel build (-j 24 and full lto, my own .config)
>>>>>> and an application build (also with a lot of parallelism)
>>>>>> with three different kernels:
>>>>>>
>>>>>> a) Cache aware scheduling completely configured off
>>>>>>
>>>>>> b) Cache aware scheduling turned on, but without patch
>>>>>>
>>>>>> c) Cache aware scheduling turned on, with patch
>>>>>>
>>>>>> Big/little scheduling was always on,
>>>>>> Mario's patch was always applied
>>>>>> (without it, results are significantly worse,
>>>>>
>>>>> Sorry, I am a bit confused. You mentioned later the result for (b)
>>>>> and (c) are about the same with or without the patch
>>>>> exposing debugfs (commit c1e7fe5e75ed11fa85368e5a186472afd3858f3a
>>>>> Mario mentioned in another mail).
>>>>> But here you say the result is much worse without Mario's patch.
>>>>> Is Mario's patch the one above or some other patch?
>>>>
>>>> The with/without patch in (b) and (c)
>>>> refers to the patch you sent on 31/08/2026
>>>> ( https://lore.kernel.org/lkml/20260825174112.2580942-1-tim.c.chen@linux.intel.com/ ),
>>>> not to Mario's patch.
>>>>
>>>
>>> Just to clarify Mario's patch in this context refers to the fix to
>>> ITMT/debugfs fixes as Klaus doesn't nominally enable debugfs in Kconfig:
>>>
>>> eaece4849991d62fcd6f46637c55dcce00e25d70
>>>
>>
>> Ricardo reminded me that AMD's hybrid CPU relies on SD_ASYM_PACKING instead
>> of SD_ASYM_CPUCAPACITY. So the patch I pointed to
>> (https://lore.kernel.org/lkml/20260825174112.2580942-1-tim.c.chen@linux.intel.com/)
>> only fixes the SD_ASYM_CPUCAPACITY case and would not have an effect on
>> your test system.
>>
>> The fact that ITMT needs to be turned on to improve performance also point
>> in that direction.
>>
>> There was a bug that Chen Yu fixes for ITMT compatability with cache aware scheduling.
>> It prevents a task from getting stuck in the wrong LLC in the ITMT case
>> (https://lore.kernel.org/lkml/20260810033742.1688718-1-yu.c.chen@intel.com/).
>> Klaus, Can you apply that with Mario's ITMT/debugfs patch to see if that
>> improves performance on your system?
>>
>> Tim
>
> Yes, that patch tries to coordinate ITMT with cache-aware scheduling. It
> would also
> be helpful to get a dump of /sys/kernel/sched/debug/domains/* to
> confirm that the
> SD_ASYM_PACKING flag is set at the MC domains as well as
> /sys/kernel/debug/x86/sched_itmt_enabled
> to double-check that ITMT is enabled and
> /sys/kernel/debug/x86/sched_core_priority to look at
> CPU priorities.
>
> thanks,
> Chenyu
next prev parent reply other threads:[~2026-09-14 10:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-29 15:42 Cache-aware scheduling does not work well with amd big/little cores Klaus Kusche
2026-08-31 1:53 ` Mario Limonciello
2026-08-31 2:08 ` Chen, Yu C
2026-08-31 11:24 ` Klaus Kusche
2026-08-31 17:29 ` Tim Chen
2026-08-31 18:49 ` Klaus Kusche
2026-08-31 18:53 ` Mario Limonciello
2026-09-05 15:40 ` Klaus Kusche
2026-09-08 21:54 ` Tim Chen
2026-09-09 8:59 ` Klaus Kusche
2026-09-09 13:19 ` Mario Limonciello
2026-09-09 19:51 ` Tim Chen
2026-09-10 1:29 ` Chen, Yu C
2026-09-14 10:27 ` Klaus Kusche [this message]
2026-09-14 13:13 ` Chen Yu
2026-09-16 14:52 ` Klaus Kusche
2026-09-23 23:47 ` Tim Chen
2026-09-25 8:59 ` Klaus Kusche
2026-09-25 19:19 ` Tim Chen
2026-09-27 10:47 ` Klaus Kusche
2026-09-28 17:22 ` Tim Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6b173ff1-6fde-401d-a4a8-6fa8bbe3287c@computerix.info \
--to=klaus.kusche@computerix.info \
--cc=KPrateek.Nayak@amd.com \
--cc=Vishal.Badole@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=peterz@infradead.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=ricardo.neri@intel.com \
--cc=tim.c.chen@linux.intel.com \
--cc=x86@kernel.org \
--cc=yu.c.chen@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.