summaryrefslogtreecommitdiffstats
path: root/docs/virtio-balloon-stats.txt
diff options
context:
space:
mode:
authorDaniel Henrique Barboza2021-11-10 13:39:21 +0100
committerCédric Le Goater2021-11-10 13:48:13 +0100
commit1fde73bcd72d94a6215ec7cd599aa5c7e6591d29 (patch)
tree5aa6d1068791b697f9649932342c4deb7988c11a /docs/virtio-balloon-stats.txt
parenttarget/ppc: Fix register update on lf[sd]u[x]/stf[sd]u[x] (diff)
downloadqemu-1fde73bcd72d94a6215ec7cd599aa5c7e6591d29.tar.gz
qemu-1fde73bcd72d94a6215ec7cd599aa5c7e6591d29.tar.xz
qemu-1fde73bcd72d94a6215ec7cd599aa5c7e6591d29.zip
spapr_numa.c: fix FORM1 distance-less nodes
Commit 71e6fae3a99 fixed an issue with FORM2 affinity guests with NUMA nodes in which the distance info is absent in machine_state->numa_state->nodes. This happens when QEMU adds a default NUMA node and when the user adds NUMA nodes without specifying the distances. During the discussions of the forementioned patch [1] it was found that FORM1 guests were behaving in a strange way in the same scenario, with the kernel seeing the distances between the nodes as '160', as we can see in this example with 4 NUMA nodes without distance information: $ numactl -H available: 4 nodes (0-3) (...) node distances: node 0 1 2 3 0: 10 160 160 160 1: 160 10 160 160 2: 160 160 10 160 3: 160 160 160 10 Turns out that we have the same problem with FORM1 guests - we are calculating associativity domain using zeroed values. And as it also turns out, the solution from 71e6fae3a99 applies to FORM1 as well. This patch creates a wrapper called 'get_numa_distance' that contains the logic used in FORM2 to define node distances when this information is absent. This helper is then used in all places where we need to read distance information from machine_state->numa_state->nodes. That way we'll guarantee that the NUMA node distance is always being curated before being used. After this patch, the FORM1 guest mentioned above will have the following topology: $ numactl -H available: 4 nodes (0-3) (...) node distances: node 0 1 2 3 0: 10 20 20 20 1: 20 10 20 20 2: 20 20 10 20 3: 20 20 20 10 This is compatible with what FORM2 guests and other archs do in this case. [1] https://lists.gnu.org/archive/html/qemu-devel/2021-11/msg01960.html Fixes: 690fbe4295d5 ("spapr_numa: consider user input when defining associativity") CC: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> CC: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Diffstat (limited to 'docs/virtio-balloon-stats.txt')
0 files changed, 0 insertions, 0 deletions