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

On 12/10/2026 04:20, K Prateek Nayak wrote:

Hello Mete,

On 10/7/2026 3:49 PM, Mete Durlu wrote:

quoted

On 01/10/2026 21:28, K Prateek Nayak wrote:

quoted

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