Re: [PATCH] s390/topology: Enable ASYM_PACKING to establish cpu priority

[Mete Durlu <meted@linux.ibm.com>]

On 01/09/2026 17:30, Heiko Carstens wrote:
> On Tue, Sep 01, 2026 at 04:40:26PM +0200, Mete Durlu wrote:
>> On s390 LPARs the hypervisor assigns varying CPU runtime capacities
>> under vertical polarization, making CPUs unequal. Add SD_ASYM_PACKING
>> into topology level flag callbacks so the scheduler keeps busier
>> scheduling groups packed onto higher-capacity CPUs.
>> Implement arch_asym_cpu_priority() using smp_cpu_get_capacity() as
>> the decision factor.
> 
> ...
>> Subtract the CPU number so that the CPUs with lower ids are prioritized.
> 
> Why?

In short terms, this prioritization prevents tasks from being scattered
all over and keeps them in a smaller region of cores. This is one of
reasons for performance improvements.
Subtracting CPU id also helps when all vertical high COREs are busy
and selection has to be made between vertical lows with equal capacity.
In such scenarios best performance is observed when the tasks are
grouped closer.

>> Only enabled on LPAR level as other guest levels either do not have
>> vertical polarization (which causes asymmetric CPUs), or machine backed
>> topology.
> 
> ...
> 
>> +static int s390_core_flags(void)
>> +{
>> +	int flags = cpu_core_flags();
>> +
>> +	if (machine_is_lpar())
>> +		flags |= SD_ASYM_PACKING;
>> +	return flags;
>> +}
> 
> Why is this machine_is_lpar()? This should actually test if cpu
> polarization is available to make this independent of some random
> environment test.

Ah, I wrongly thought that running on LPAR automatically means
that the configuration will have topology and polarization.

> Furthermore to me this reads like the above only makes sense in case of
> vertical polarization. What happens in case of horizontal polarization?
> Does SD_ASYM_PACKING have any negative impact for that case?

I was hoping that this grouping effect I described above would help
on horizontal polarization but the initial benchmarks show that the
the impact is a bit different and chaotic for horizontal polarization.
I'll conduct a couple of more runs to make sure.

OTOH, now that I think about it again by definition horizontal
polarization should treat all CPUs equally and now we are telling
the scheduler that they are not equal which does not make any sense.

I think the logical option is to tie presence of vertical polarization.
Oh and I just realized I missed the case for DEDICATED configuration.
I'll come back with more experiments and improve the commit description.

Thank you for having a look Heiko!