From: Mete Durlu <meted@linux.ibm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Shrikanth Hegde <sshegde@linux.ibm.com>,
Andrea Righi <arighi@nvidia.com>, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
K Prateek Nayak <kprateek.nayak@amd.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
Tim Chen <tim.c.chen@linux.intel.com>,
Chen Yu <yu.c.chen@intel.com>,
Ilya Leoshkevich <iii@linux.ibm.com>,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH RFC 0/2] sched: Introduce idle SMT priority for asymmetric capacity systems
Date: Mon, 12 Oct 2026 13:04:33 +0200 [thread overview]
Message-ID: <d412d939-4704-4246-a9bd-b49b457099b8@linux.ibm.com> (raw)
In-Reply-To: <CAKfTPtCianGNWSu0s2J_B_aO_rtKWO17k9guYmwgXXLUHQE+SA@mail.gmail.com>
On 09/10/2026 17:32, Vincent Guittot wrote:
> On Thu, 8 Oct 2026 at 17:25, Mete Durlu <meted@linux.ibm.com> wrote:
>>
>> On 08/10/2026 16:58, Shrikanth Hegde wrote:
>>> Hi Meter/Andrea.
>>>
>>> On 10/8/26 5:40 PM, Andrea Righi wrote:
>>>> Hi Mete,
>>>>
>>>> On Thu, Oct 08, 2026 at 10:30:46AM +0200, Mete Durlu wrote:
>>>>> Summary
>>>>> ===========================================================================
>>>>> On systems with asymmetric CPU capacities, the scheduler prefers
>>>>> fully idle
>>>>> cores over idle SMT siblings of busy cores. This works generally well
>>>>> but
>>>>> virtualized platforms where low capacity cores should be avoided are not
>>>>> considered. Introduce a new config option and arch hook to prioritize
>>>>> SMT utilization.
>>>
>>> That's true only under physical CPU contention right? or is it always?
>>
>> Right, because of that s390 treats all CPUs as equal and starts to
>> assign lower capacities to CPUs with low entitlement once a certain
>> steal time threshold is crossed (aka physical CPU contention).
Hi,
Sorry for causing a misunderstanding. I should have been more patient
and detailed while writing my reply.
> I'm not sure to get what your topology is because "if s390 treats all
> CPUs as equal" then you should never use select_idle_capacity()
> because their capacity should be fixed and equal and
> SD_ASYM_CPUCAPACITY_FULL never set.
On s390 the entitlement of the vCPUs are signified by an arch specific
value we call polarization. We can tell which vCPUs are assigned high
and low entitlement. This entitlement value tells us which vCPUs are
prone to experience steal time first. Without any contention all
vCPUs behave and perform *almost* the same(of course, we want
some priority for CPUs with high entitlement).
Prior to experiencing steal time(it's what we use to determine
contention) to get the most out of the system we assign all vCPUs
the same capacities, making the system symmetric like you say.
While there is no contention s390's vCPUs also perform better if
fully idle cores are selected for task placement.
> If your hypervisor lowers the capacity once a certain threshold is
> crossed, we already account for the steal time in the scheduler with
> irq and remove it from the capacity available for tasks but the
> original capacity doesn't change.
s390's linux implementation has a mechanism called hiperdispatch,
that checks topology changes along with system steal time (and soon
the total free capacity of the pyhsical machine) periodically and
makes vCPU capacity adjustments accordingly.
After steal time starts ramping up and cross a certain threshold,
we start assigning lower capacities to vCPUs with low entitlement to
hint the scheduler that they should be avoided.
In this asymmetric configuration, utilizing low capacity but fully idle
cores hurt performance. Instead packing the tasks first to SMT siblings
of high capacity cores would give s390 a lot of benefit.
I hope that clears some of the fog that I unintentionally created.
[..snip..]
next prev parent reply other threads:[~2026-10-12 11:05 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 8:30 Mete Durlu
2026-10-08 8:30 ` [PATCH RFC 1/2] kernel/sched: Introduce idle SMT priority Mete Durlu
2026-10-08 8:30 ` [PATCH RFC 2/2] s390/topology: Enable SCHED_IDLE_SMT_PRIO Mete Durlu
2026-10-08 12:10 ` [PATCH RFC 0/2] sched: Introduce idle SMT priority for asymmetric capacity systems Andrea Righi
2026-10-08 14:58 ` Shrikanth Hegde
2026-10-08 15:24 ` Mete Durlu
2026-10-08 15:44 ` Shrikanth Hegde
2026-10-09 15:12 ` Andrea Righi
2026-10-09 15:35 ` Shrikanth Hegde
2026-10-12 12:32 ` Mete Durlu
2026-10-12 13:49 ` Shrikanth Hegde
2026-10-09 15:32 ` Vincent Guittot
2026-10-12 11:04 ` Mete Durlu [this message]
2026-10-12 14:49 ` Vincent Guittot
2026-10-08 21:52 ` Tim Chen
2026-10-08 21:29 ` Tim Chen
2026-10-12 10:41 ` Mete Durlu
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=d412d939-4704-4246-a9bd-b49b457099b8@linux.ibm.com \
--to=meted@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=arighi@nvidia.com \
--cc=borntraeger@linux.ibm.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=iii@linux.ibm.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sshegde@linux.ibm.com \
--cc=svens@linux.ibm.com \
--cc=tim.c.chen@linux.intel.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®