From: Tobias Huschle <huschle@linux.ibm.com>
To: Shrikanth Hegde <sshegde@linux.ibm.com>, linux-kernel@vger.kernel.org
Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
vschneid@redhat.com, linux-s390@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH 2/2] s390/topology: Add initial implementation for selection of parked CPUs
Date: Mon, 9 Dec 2024 09:18:51 +0100 [thread overview]
Message-ID: <5e3c0502-1a28-483c-a831-6d1f814501da@linux.ibm.com> (raw)
In-Reply-To: <1f7ad21c-372f-4d7d-b3dc-9a2fb194b704@linux.ibm.com>
On 05/12/2024 19:12, Shrikanth Hegde wrote:
>
>
> On 12/4/24 16:51, Tobias Huschle wrote:
>> In this simplified example, vertical low CPUs are parked generally.
>> This will later be adjusted by making the parked state dependent
>> on the overall utilization on the underlying hypervisor.
>>
>> Vertical lows are always bound to the highest CPU IDs. This implies that
>> the three types of vertically polarized CPUs are always clustered by ID.
>> This has the following implications:
>> - There can be scheduler domains consisting of only vertical highs
>> - There can be scheduler domains consisting of only vertical lows
>>
>
> A sched domain can have combination of these two as well. Is that not
> possible on s390?
A combination is possible. It depends on the algorithm of the hypervisor
how many of those mixed groups might be possible.
>
>> Signed-off-by: Tobias Huschle <huschle@linux.ibm.com>
>> ---
>> arch/s390/include/asm/topology.h | 3 +++
>> arch/s390/kernel/topology.c | 5 +++++
>> 2 files changed, 8 insertions(+)
>>
>> diff --git a/arch/s390/include/asm/topology.h b/arch/s390/include/asm/
>> topology.h
>> index cef06bffad80..e86afeccde35 100644
>> --- a/arch/s390/include/asm/topology.h
>> +++ b/arch/s390/include/asm/topology.h
>> @@ -99,6 +99,9 @@ static inline int numa_node_id(void)
>> #endif /* CONFIG_NUMA */
>> +#define arch_cpu_parked cpu_parked
>> +int cpu_parked(int cpu);
>> +
>> #include <asm-generic/topology.h>
>> #endif /* _ASM_S390_TOPOLOGY_H */
>> diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
>> index 4f9c301a705b..1032b65da574 100644
>> --- a/arch/s390/kernel/topology.c
>> +++ b/arch/s390/kernel/topology.c
>> @@ -299,6 +299,11 @@ void store_topology(struct sysinfo_15_1_x *info)
>> stsi(info, 15, 1, topology_mnest_limit());
>> }
>> +int cpu_parked(int cpu)
>> +{
>> + return smp_cpu_get_polarization(cpu) == POLARIZATION_VL;
>> +}
>
> Curious to know how this smp_cpu_get_polarization gets updated at
> runtime? is it done by add_cpus_to_mask?
The polarization itself can get updated by the underlying hypervisor,
which passes that information on to the Linux kernel.
A future implementation will not rely on the polarization as the main
criterion but take more data points into account to allow a correct
adaption to the load of the system.
Only using polarization would deny us the opportunity to overconsume on
our entitlement if the machine has enough spare capacity. This patch
just wants to be a tiny example on how this could be used.
>
>> +
>> static void __arch_update_dedicated_flag(void *arg)
>> {
>> if (topology_cpu_dedicated(smp_processor_id()))
next prev parent reply other threads:[~2024-12-09 8:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-04 11:21 [RFC PATCH 0/2] sched/fair: introduce new scheduler group type group_parked Tobias Huschle
2024-12-04 11:21 ` [RFC PATCH 1/2] " Tobias Huschle
2024-12-05 18:04 ` Shrikanth Hegde
2024-12-09 8:17 ` Tobias Huschle
2024-12-04 11:21 ` [RFC PATCH 2/2] s390/topology: Add initial implementation for selection of parked CPUs Tobias Huschle
2024-12-05 18:12 ` Shrikanth Hegde
2024-12-09 8:18 ` Tobias Huschle [this message]
2024-12-05 14:48 ` [RFC PATCH 0/2] sched/fair: introduce new scheduler group type group_parked Shrikanth Hegde
2024-12-09 8:05 ` Tobias Huschle
2024-12-10 20:24 ` Shrikanth Hegde
2024-12-16 16:13 ` Tobias Huschle
2025-01-14 18:13 ` Tobias Huschle
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=5e3c0502-1a28-483c-a831-6d1f814501da@linux.ibm.com \
--to=huschle@linux.ibm.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sshegde@linux.ibm.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.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®