[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v8 08/12] s390x/cpu_topology: implementing numa for the s390x
From: |
Janis Schoetterl-Glausch |
Subject: |
Re: [PATCH v8 08/12] s390x/cpu_topology: implementing numa for the s390x topology |
Date: |
Fri, 15 Jul 2022 11:11:12 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 |
On 7/14/22 22:17, Pierre Morel wrote:
>
>
> On 7/14/22 16:57, Janis Schoetterl-Glausch wrote:
>> On 6/20/22 16:03, Pierre Morel wrote:
>>> S390x CPU Topology allows a non uniform repartition of the CPU
>>> inside the topology containers, sockets, books and drawers.
>>>
>>> We use numa to place the CPU inside the right topology container
>>> and report the non uniform topology to the guest.
>>>
>>> Note that s390x needs CPU0 to belong to the topology and consequently
>>> all topology must include CPU0.
>>>
>>> We accept a partial QEMU numa definition, in that case undefined CPUs
>>> are added to free slots in the topology starting with slot 0 and going
>>> up.
>>
>> I don't understand why doing it this way, via numa, makes sense for us.
>> We report the topology to the guest via STSI, which tells the guest
>> what the topology "tree" looks like. We don't report any numa distances to
>> the guest.
>> The natural way to specify where a cpu is added to the vm, seems to me to be
>> by specify the socket, book, ... IDs when doing a device_add or via -device
>> on
>> the command line.
>>
>> [...]
>>
>
> It is a choice to have the core-id to determine were the CPU is situated in
> the topology.
>
> But yes we can chose the use drawer-id,book-id,socket-id and use a core-id
> starting on 0 on each socket.
>
> It is not done in the current implementation because the core-id implies the
> socket-id, book-id and drawer-id together with the smp parameters.
>
>
Regardless of whether the core-id or the combination of socket-id, book-id ..
is used to specify where a CPU is
located, why use the numa framework and not just device_add or -device ?
That feels way more natural since it should already just work if you can do
hotplug.
At least with core-id and I suspect with a subset of your changes also with
socket-id, etc.
Whereas numa is an awkward fit since it's for specifying distances between
nodes, which we don't do,
and you have to use a hack to get it to specify which CPUs to plug (via setting
arch_id to -1).
- Re: [PATCH v8 08/12] s390x/cpu_topology: implementing numa for the s390x topology, Janis Schoetterl-Glausch, 2022/07/14
- Re: [PATCH v8 08/12] s390x/cpu_topology: implementing numa for the s390x topology, Pierre Morel, 2022/07/14
- Re: [PATCH v8 08/12] s390x/cpu_topology: implementing numa for the s390x topology,
Janis Schoetterl-Glausch <=
- Re: [PATCH v8 08/12] s390x/cpu_topology: implementing numa for the s390x topology, Pierre Morel, 2022/07/15
- Re: [PATCH v8 08/12] s390x/cpu_topology: implementing numa for the s390x topology, Janis Schoetterl-Glausch, 2022/07/20
- Re: [PATCH v8 08/12] s390x/cpu_topology: implementing numa for the s390x topology, Pierre Morel, 2022/07/21
- Re: [PATCH v8 08/12] s390x/cpu_topology: implementing numa for the s390x topology, Janis Schoetterl-Glausch, 2022/07/21
- Re: [PATCH v8 08/12] s390x/cpu_topology: implementing numa for the s390x topology, Pierre Morel, 2022/07/21
- Re: [PATCH v8 08/12] s390x/cpu_topology: implementing numa for the s390x topology, Janis Schoetterl-Glausch, 2022/07/22