linux-kernel - Re: [RFC PATCH 2/2] s390/topology: Add initial implementation for selection of parked CPUs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5e3c0502-1a28-483c-a831-6d1f814501da@linux.ibm.com>
Date: Mon, 9 Dec 2024 09:18:51 +0100
From: Tobias Huschle <huschle@...ux.ibm.com>
To: Shrikanth Hegde <sshegde@...ux.ibm.com>, linux-kernel@...r.kernel.org
Cc: mingo@...hat.com, peterz@...radead.org, juri.lelli@...hat.com,
        vincent.guittot@...aro.org, dietmar.eggemann@....com,
        rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
        vschneid@...hat.com, linux-s390@...r.kernel.org,
        linuxppc-dev@...ts.ozlabs.org
Subject: Re: [RFC PATCH 2/2] s390/topology: Add initial implementation for
 selection of parked CPUs



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@...ux.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()))