Re: [RFC PATCH v3 07/13] s390/topology: Initialize sbm topology during topology_init_early()

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

On 12/10/2026 04:20, K Prateek Nayak wrote:
> Hello Mete,
> 
> On 10/7/2026 3:49 PM, Mete Durlu wrote:
>> On 01/10/2026 21:28, K Prateek Nayak wrote:
>>> When the topology mode is TOPOLOGY_MODE_HW, topology_init_early()
>>> already parses the set of socket present on the system.
>>>
>>> Use the socket_info to configure the sparsebitmask (sbm) properties for
>>> the system - namely the number of sockets and maximum threads in a
>>> socket instance.
>>>
>>> arch_sbm_cpu_instance_id() traverses all socket instances to find
>>> a matching CPU which is not optimal but instance ID is only checked
>>> when the CPU is coming online. Since this is a rare event, the
>>> inefficiency is tolerable.
>>>
>>> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
>>> ---
>>> Build tested with LKP's s390 randconfig with QEMU cmdline:
>>>
>>>     qemu-system-s390x \
>>>     -cpu max \
>>>     -smp 2 \
>>>     -m 2048 \
>>>     -kernel ./arch/s390/boot/vmlinux  \
>>>     -append "console=ttyAMA0 earlycon ignore_loglevel log_buf_len=10M print_fatal_signals=1 LOGLEVEL=8 sched_debug" \
>>>     -nographic
>>>
>>> Note: Since ctop needs KVM acceleration to emulate TOPOLOGY_MODE_HW, the
>>> actual spasemask setting is only build tested at the moment.
>>>
>>> XXX: Any way around this using cross-compile and QEMU?
>>> ---
>>>    arch/s390/kernel/topology.c | 52 +++++++++++++++++++++++++++++++++++++
>>>    1 file changed, 52 insertions(+)
>>>
>>> diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
>>> index 1377c6f3f670..80dc51f5ce6f 100644
>>> --- a/arch/s390/kernel/topology.c
>>> +++ b/arch/s390/kernel/topology.c
>>> @@ -20,6 +20,7 @@
>>>    #include <linux/init.h>
>>>    #include <linux/slab.h>
>>>    #include <linux/cpu.h>
>>> +#include <linux/sbm.h>
>>>    #include <linux/smp.h>
>>>    #include <linux/mm.h>
>>>    #include <linux/nodemask.h>
>>> @@ -561,6 +562,55 @@ static int __init detect_polarization(union topology_entry *tle)
>>>        return tl_core->pp != POLARIZATION_HRZ;
>>>    }
>>
>> topology_init_early() is called once during early boot and never again.
>> Considering that s390's topology can change during runtime this
>> implementation won't work as sbm won't be able to adapt.
>> On s390 max_threads_per_instance can change during runtime.
>>
>> Like sashiko pointed out, this approach also does not consider
>> any newly added cpus.
>>
>> IMHO, there is a slight redesign required so that smb_set_topology()
>> and smb_init() can be called each time a topology rebuild is necessary.
> 
> So based on my limited understanding, doesn't store_topology() populate
> the mask for the entire system on s390? Are you saying that can change
> or that stsi() may return a partial topology for only the online CPUs?

On s390 LPAR(logical partition) cpu topology can change during runtime.
Depending on the decisions made by the underlying hypervisor there
can be topology adjustments to find the optimal LPAR placement within
the physical machine.

To give a concrete example:
On an LPAR with 7 cores spanning 2 chips with the following topology;

CPU NODE DRAWER BOOK SOCKET CORE ONLINE ADDRESS
   0    0      0    0      0    0    yes 0
   1    0      0    0      0    0    yes 1
   2    0      0    0      0    1    yes 2
   3    0      0    0      0    1    yes 3
   4    0      0    0      0    2    yes 4
   5    0      0    0      0    2    yes 5
   6    0      0    0      0    3    yes 6
   7    0      0    0      0    3    yes 7
   8    0      0    0      1    4    yes 8
   9    0      0    0      1    4    yes 9
  10    0      0    0      1    5    yes 10
  11    0      0    0      1    5    yes 11
  12    0      0    0      1    6    yes 12
  13    0      0    0      1    6    yes 13

Initially max_threads_per_instance would be 8, right?
After a topology update from the hypervisor we can end up with
all cores placed in the same chip.

CPU NODE DRAWER BOOK SOCKET CORE ONLINE ADDRESS
   0    0      0    0      0    0    yes 0
   1    0      0    0      0    0    yes 1
   2    0      0    0      0    1    yes 2
   3    0      0    0      0    1    yes 3
   4    0      0    0      0    2    yes 4
   5    0      0    0      0    2    yes 5
   6    0      0    0      0    3    yes 6
   7    0      0    0      0    3    yes 7
   8    0      0    0      0    4    yes 8
   9    0      0    0      0    4    yes 9
  10    0      0    0      0    5    yes 10
  11    0      0    0      0    5    yes 11
  12    0      0    0      0    6    yes 12
  13    0      0    0      0    6    yes 13

According to the new topology max_threads_per_instance now
should be 14.

On top of that we support hotplugging in new CPUs which
means we can then get a new topology after adding a
completely new core. (QEMU supports feature [1])

CPU NODE DRAWER BOOK SOCKET CORE ONLINE ADDRESS
   0    0      0    0      0    0    yes 0
   1    0      0    0      0    0    yes 1
   2    0      0    0      0    1    yes 2
   3    0      0    0      0    1    yes 3
   4    0      0    0      0    2    yes 4
   5    0      0    0      0    2    yes 5
   6    0      0    0      0    3    yes 6
   7    0      0    0      0    3    yes 7
   8    0      0    0      0    4    yes 8
   9    0      0    0      0    4    yes 9
  10    0      0    0      0    5    yes 10
  11    0      0    0      0    5    yes 11
  12    0      0    0      0    6    yes 12
  13    0      0    0      0    6    yes 13
  14    0      0    0      0    7    yes 14
  15    0      0    0      0    7    yes 15

max_threads_per_instance should now be 16.

Considering these cases I asked for a redesign that
allows smb_set_topology() and smb_init() to be called
during topology_rebuild() operations.

Please correct me if I misunderstood a something
from your proposal.

[1] https://www.qemu.org/docs/master/system/s390x/cpu-topology.html

Thanks,
-Mete