From nobody Sun May 5 11:25:11 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1551455118820757.6104961081888; Fri, 1 Mar 2019 07:45:18 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0C15C308C4CB; Fri, 1 Mar 2019 15:42:42 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CBF64608DA; Fri, 1 Mar 2019 15:42:41 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 8A9EC131F9; Fri, 1 Mar 2019 15:42:41 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x21FgOWc004593 for ; Fri, 1 Mar 2019 10:42:24 -0500 Received: by smtp.corp.redhat.com (Postfix) id AC15560CD1; Fri, 1 Mar 2019 15:42:24 +0000 (UTC) Received: from dell-r430-03.lab.eng.brq.redhat.com (dell-r430-03.lab.eng.brq.redhat.com [10.37.153.18]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0DDEA60C66; Fri, 1 Mar 2019 15:42:20 +0000 (UTC) From: Igor Mammedov To: qemu-devel@nongnu.org Date: Fri, 1 Mar 2019 16:42:15 +0100 Message-Id: <1551454936-205218-2-git-send-email-imammedo@redhat.com> In-Reply-To: <1551454936-205218-1-git-send-email-imammedo@redhat.com> References: <1551454936-205218-1-git-send-email-imammedo@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-loop: libvir-list@redhat.com Cc: peter.maydell@linaro.org, ehabkost@redhat.com, libvir-list@redhat.com, qemu-arm@nongnu.org, qemu-ppc@nongnu.org, pbonzini@redhat.com, david@gibson.dropbear.id.au Subject: [libvirt] [PATCH 1/2] numa: deprecate 'mem' parameter of '-numa node' option X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.44]); Fri, 01 Mar 2019 15:42:42 +0000 (UTC) Content-Type: text/plain; charset="utf-8" The parameter allows to configure fake NUMA topology where guest VM simulates NUMA topology but not actually getting a performance benefits from it. The same or better results could be achieved using 'memdev' parameter. In light of that any VM that uses NUMA to get its benefits should use 'memdev' and to allow transition initial RAM to device based model, deprecate 'mem' parameter as its ad-hoc partitioning of initial RAM MemoryRegion can't be translated to memdev based backend transparently to users and in compatible manner (migration wise). That will also allow to clean up a bit our numa code, leaving only 'memdev' impl. in place and several boards that use node_mem to generate FDT/ACPI description from it. Signed-off-by: Igor Mammedov --- numa.c | 2 ++ qemu-deprecated.texi | 14 ++++++++++++++ 2 files changed, 16 insertions(+) diff --git a/numa.c b/numa.c index 3875e1e..2205773 100644 --- a/numa.c +++ b/numa.c @@ -121,6 +121,8 @@ static void parse_numa_node(MachineState *ms, NumaNodeO= ptions *node, =20 if (node->has_mem) { numa_info[nodenr].node_mem =3D node->mem; + warn_report("Parameter -numa node,mem is deprecated," + " use -numa node,memdev instead"); } if (node->has_memdev) { Object *o; diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi index 45c5795..73f99d4 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -60,6 +60,20 @@ Support for invalid topologies will be removed, the user= must ensure topologies described with -smp include all possible cpus, i.e. @math{@var{sockets} * @var{cores} * @var{threads} =3D @var{maxcpus}}. =20 +@subsection -numa node,mem=3D@var{size} (since 4.0) + +The parameter @option{mem} of @option{-numa node} is used to assign a part= of +guest RAM to a NUMA node. But when using it, it's impossible to manage spe= cified +size on the host side (like bind it to a host node, setting bind policy, .= ..), +so guest end-ups with the fake NUMA configuration with suboptiomal perform= ance. +However since 2014 there is an alternative way to assign RAM to a NUMA node +using parameter @option{memdev}, which does the same as @option{mem} and h= as +an ability to actualy manage node RAM on the host side. Use parameter +@option{memdev} with @var{memory-backend-ram} backend as an replacement for +parameter @option{mem} to achieve the same fake NUMA effect or a properly +configured @var{memory-backend-file} backend to actually benefit from NUMA +configuration. + @section QEMU Machine Protocol (QMP) commands =20 @subsection block-dirty-bitmap-add "autoload" parameter (since 2.12.0) --=20 2.7.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list From nobody Sun May 5 11:25:11 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1551454968719155.87730302785667; Fri, 1 Mar 2019 07:42:48 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C1A0FA756C; Fri, 1 Mar 2019 15:42:46 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 98EFD60A9A; Fri, 1 Mar 2019 15:42:46 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 60D793FB14; Fri, 1 Mar 2019 15:42:46 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x21FgQ1R004857 for ; Fri, 1 Mar 2019 10:42:26 -0500 Received: by smtp.corp.redhat.com (Postfix) id CDC9160BE2; Fri, 1 Mar 2019 15:42:26 +0000 (UTC) Received: from dell-r430-03.lab.eng.brq.redhat.com (dell-r430-03.lab.eng.brq.redhat.com [10.37.153.18]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0591C60BE0; Fri, 1 Mar 2019 15:42:24 +0000 (UTC) From: Igor Mammedov To: qemu-devel@nongnu.org Date: Fri, 1 Mar 2019 16:42:16 +0100 Message-Id: <1551454936-205218-3-git-send-email-imammedo@redhat.com> In-Reply-To: <1551454936-205218-1-git-send-email-imammedo@redhat.com> References: <1551454936-205218-1-git-send-email-imammedo@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-loop: libvir-list@redhat.com Cc: peter.maydell@linaro.org, ehabkost@redhat.com, libvir-list@redhat.com, qemu-arm@nongnu.org, qemu-ppc@nongnu.org, pbonzini@redhat.com, david@gibson.dropbear.id.au Subject: [libvirt] [PATCH 2/2] numa: deprecate implict memory distribution between nodes X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 01 Mar 2019 15:42:47 +0000 (UTC) Content-Type: text/plain; charset="utf-8" Implict RAM distribution between nodes has exactly the same issues as: "numa: deprecate 'mem' parameter of '-numa node' option" only with QEMU being the user that's 'adding' 'mem' parameter. Depricate it, to get it out of the way so that we could switch to consistent guest RAM allocation using memory backends and possibly memory devices later on top of that. Signed-off-by: Igor Mammedov --- numa.c | 3 +++ qemu-deprecated.texi | 7 +++++++ 2 files changed, 10 insertions(+) diff --git a/numa.c b/numa.c index 2205773..6d45a1f 100644 --- a/numa.c +++ b/numa.c @@ -409,6 +409,9 @@ void numa_complete_configuration(MachineState *ms) if (i =3D=3D nb_numa_nodes) { assert(mc->numa_auto_assign_ram); mc->numa_auto_assign_ram(mc, numa_info, nb_numa_nodes, ram_siz= e); + warn_report("Default splitting of RAM between nodes is depreca= ted," + " Use '-numa node,memdev' to explictly define RAM" + " allocation per node"); } =20 numa_total =3D 0; diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi index 73f99d4..09bec7d 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -74,6 +74,13 @@ parameter @option{mem} to achieve the same fake NUMA eff= ect or a properly configured @var{memory-backend-file} backend to actually benefit from NUMA configuration. =20 +@subsection -numa node (without memory specified) (since 4.0) + +Splitting RAM by default between NUMA nodes has the same issues as @option= {mem} +parameter described above with a difference that role of the user plays QE= MU +using generic splitting rule or a board specific one. Use @option{memdev} = with +@var{memory-backend-ram} backend to define mapping explictly instead. + @section QEMU Machine Protocol (QMP) commands =20 @subsection block-dirty-bitmap-add "autoload" parameter (since 2.12.0) --=20 2.7.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list