qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/3] numa: Initialize node initiator with respect to .has_cpu


From: Michal Privoznik
Subject: Re: [PATCH 3/3] numa: Initialize node initiator with respect to .has_cpu
Date: Thu, 11 Jun 2020 16:42:21 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0

On 6/5/20 3:52 AM, Tao Xu wrote:
On 6/3/20 5:16 PM, Michal Privoznik wrote:
On 6/2/20 10:00 AM, Tao Xu wrote:

On 6/1/2020 4:10 PM, Michal Privoznik wrote:
On 5/29/20 5:09 PM, Igor Mammedov wrote:
On Fri, 29 May 2020 15:33:48 +0200
Michal Privoznik <mprivozn@redhat.com> wrote:

The initiator attribute of a NUMA node is documented as the 'NUMA
node that has best performance to given NUMA node'. If a NUMA
node has at least one CPU there can hardly be a different node
with better performace and thus all NUMA nodes which have a CPU
are initiators to themselves. Reflect this fact when initializing
the attribute.

It is not true in case of the node is memory-less

Are you saying that if there's a memory-less NUMA node, then it needs to
have initiator set too? Asking mostly out of curiosity because we don't
allow memory-less NUMA nodes in Libvirt just yet. Nor cpu-less, but my
patches that I'm referring to in cover letter will allow at least
cpu-less nodes. Should I allow both?
QEMU now is not support memory-less NUMA node, but in hardware may be
supported. So we reserve this type of NUMA node for future usage. And
QEMU now can support cpu-less NUMA node, for emulating some "slow"
memory(like some NVDIMM).

Oh yeah, I understand that. But it doesn't explain why initiator needs
to be specified for NUMA nodes with cpus and memory, or does it? Maybe
I'm still misunderstanding what the initiator is.


Yes, the initiator NUMA nodes with cpus and memory should be itself. In ACPI 6.3 spec, initiator is defined as:

This field is valid only if the memory controller
responsible for satisfying the access to memory
belonging to the specified memory proximity
domain is directly attached to an initiator that
belongs to a proximity domain. In that case, this
field contains the integer that represents the
proximity domain to which the initiator (Generic
Initiator or Processor) belongs. This number shall
match the corresponding entry in the SRAT table’s
processor affinity structure (e.g., Processor Local
APIC/SAPIC Affinity Structure, Processor Local
x2APIC Affinity Structure, GICC Affinity Structure) if
the initiator is a processor, or the Generic Initiator
Affinity Structure if the initator is a generic
initiator.
Note: this field provides additional information as
to the initiator node that is closest (as in directly
attached) to the memory address ranges within
the specified memory proximity domain, and
therefore should provide the best performance.

And if in the future, there is a memory-less NUMA node. Because in HMAT we describe "Memory" Proximity Domain Attributes Structure, I think we should not add memory-less NUMA node into HMAT.

Then I guess something else must be broken. Because as reported here [1] if I configure two numa nodes, both with two vCPUs and set initiators of each node to itselfs I get the following error message:

qemu-system-x86_64: -numa node,nodeid=1,cpus=2-3,initiator=1,memdev=ram-node1: The initiator of CPU NUMA node 1 should be itself

Funny about this error message is how contradictory it is. The cmd line showed in the error shows the initiator of the node 1 is indeed node 1.

1: https://lists.nongnu.org/archive/html/qemu-devel/2020-06/msg00071.html

Michal




reply via email to

[Prev in Thread] Current Thread [Next in Thread]