From nobody Thu May 2 19:59:13 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 ARC-Seal: i=1; a=rsa-sha256; t=1559205239; cv=none; d=zoho.com; s=zohoarc; b=e8tjVFbLlqPqNVrIzwkdXcVAiUnkXCVJLjLTGgoXXmD1guyuy2nGvNnBxemeS6B+HoMtygnId8rDbdX8J81RHJnK82Jyxn9Lpn/PwrD63YPRu4rVVfOrzmjc3WszvXbIbnplOh+8HHFxtlpNMT21fBQxgkbk1sLaJeDdjvkQA3c= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1559205239; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=tm58Z19gsGvZiRAt9xvW74LoSLroUlSO2R416rOag2Q=; b=TzkrWHvcGrF0Yrn1sxiMDy/e9hBAIbz+19JrukyJWodtwnp31ejyclYwPxDWSju4rY0N3j3snn+KYdTJn9Nz1/c7cAhBpB5DMjyZzXCBCAdFZvZKMMJyL5+2Y9hLydQg179u9q56GUDQPk9Up1zy1IgV4zt0aBHGLuqPsl5PIHk= ARC-Authentication-Results: i=1; mx.zoho.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 header.from= (p=none dis=none) header.from= Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1559205239143559.5409737115773; Thu, 30 May 2019 01:33:59 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EF7BF18DF60; Thu, 30 May 2019 08:33:43 +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 CA4E75D721; Thu, 30 May 2019 08:33: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 51E2F206D3; Thu, 30 May 2019 08:33:40 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x4U8Wl0q015824 for ; Thu, 30 May 2019 04:32:47 -0400 Received: by smtp.corp.redhat.com (Postfix) id 6C00B1017E3E; Thu, 30 May 2019 08:32:47 +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 270091017E2E; Thu, 30 May 2019 08:32:45 +0000 (UTC) From: Igor Mammedov To: qemu-devel@nongnu.org Date: Thu, 30 May 2019 10:33:17 +0200 Message-Id: <1559205199-233510-2-git-send-email-imammedo@redhat.com> In-Reply-To: <1559205199-233510-1-git-send-email-imammedo@redhat.com> References: <1559205199-233510-1-git-send-email-imammedo@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-loop: libvir-list@redhat.com Cc: libvir-list@redhat.com, pbonzini@redhat.com, ehabkost@redhat.com Subject: [libvirt] [PATCH v4 1/3] machine: show if CLI option '-numa node, mem' is supported in QAPI schema 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.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 30 May 2019 08:33:52 +0000 (UTC) Content-Type: text/plain; charset="utf-8" Legacy '-numa node,mem' option has a number of issues and mgmt often defaults to it. Unfortunately it's no possible to replace it with an alternative '-numa memdev' without breaking migration compatibility. What's possible though is to deprecate it, keeping option working with old machine types only. In order to help users to find out if being deprecated CLI option '-numa node,mem' is still supported by particular machine type, add new "numa-mem-supported" property to MachineInfo description in QAPI schema. "numa-mem-supported" is set to 'true' for machines that currently support NUMA, but it will be flipped to 'false' later on, once deprecation period expires and kept 'true' only for old machine types that used to support the legacy option so it won't break existing configuration that are using it. Signed-off-by: Igor Mammedov Reviewed-by: Markus Armbruster --- Notes: v4: * drop idea to use "qom-list-properties" and use MachineInfo instead which could be inspected with 'query-machines' include/hw/boards.h | 3 +++ hw/arm/virt.c | 1 + hw/i386/pc.c | 1 + hw/ppc/spapr.c | 1 + qapi/misc.json | 5 ++++- vl.c | 1 + 6 files changed, 11 insertions(+), 1 deletion(-) diff --git a/include/hw/boards.h b/include/hw/boards.h index 6f7916f..86894b6 100644 --- a/include/hw/boards.h +++ b/include/hw/boards.h @@ -158,6 +158,8 @@ typedef struct { * @kvm_type: * Return the type of KVM corresponding to the kvm-type string option or * computed based on other criteria such as the host kernel capabilitie= s. + * @numa_mem_supported: + * true if '--numa node.mem' option is supported and false otherwise */ struct MachineClass { /*< private >*/ @@ -210,6 +212,7 @@ struct MachineClass { bool ignore_boot_device_suffixes; bool smbus_no_migration_support; bool nvdimm_supported; + bool numa_mem_supported; =20 HotplugHandler *(*get_hotplug_handler)(MachineState *machine, DeviceState *dev); diff --git a/hw/arm/virt.c b/hw/arm/virt.c index bf54f10..481a603 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -1943,6 +1943,7 @@ static void virt_machine_class_init(ObjectClass *oc, = void *data) assert(!mc->get_hotplug_handler); mc->get_hotplug_handler =3D virt_machine_get_hotplug_handler; hc->plug =3D virt_machine_device_plug_cb; + mc->numa_mem_supported =3D true; } =20 static void virt_instance_init(Object *obj) diff --git a/hw/i386/pc.c b/hw/i386/pc.c index 2632b73..05b8368 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -2747,6 +2747,7 @@ static void pc_machine_class_init(ObjectClass *oc, vo= id *data) nc->nmi_monitor_handler =3D x86_nmi; mc->default_cpu_type =3D TARGET_DEFAULT_CPU_TYPE; mc->nvdimm_supported =3D true; + mc->numa_mem_supported =3D true; =20 object_class_property_add(oc, PC_MACHINE_DEVMEM_REGION_SIZE, "int", pc_machine_get_device_memory_region_size, NULL, diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index 2ef3ce4..265ecfb 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -4336,6 +4336,7 @@ static void spapr_machine_class_init(ObjectClass *oc,= void *data) * in which LMBs are represented and hot-added */ mc->numa_mem_align_shift =3D 28; + mc->numa_mem_supported =3D true; =20 smc->default_caps.caps[SPAPR_CAP_HTM] =3D SPAPR_CAP_OFF; smc->default_caps.caps[SPAPR_CAP_VSX] =3D SPAPR_CAP_ON; diff --git a/qapi/misc.json b/qapi/misc.json index 8b3ca4f..d0bdccb 100644 --- a/qapi/misc.json +++ b/qapi/misc.json @@ -2018,12 +2018,15 @@ # # @hotpluggable-cpus: cpu hotplug via -device is supported (since 2.7.0) # +# @numa-mem-supported: true if '-numa node,mem' option is supported by mac= hine +# type and false otherwise (since 4.1) +# # Since: 1.2.0 ## { 'struct': 'MachineInfo', 'data': { 'name': 'str', '*alias': 'str', '*is-default': 'bool', 'cpu-max': 'int', - 'hotpluggable-cpus': 'bool'} } + 'hotpluggable-cpus': 'bool', 'numa-mem-supported': 'bool'} } =20 ## # @query-machines: diff --git a/vl.c b/vl.c index 5550bd7..5bf17f5 100644 --- a/vl.c +++ b/vl.c @@ -1520,6 +1520,7 @@ MachineInfoList *qmp_query_machines(Error **errp) info->name =3D g_strdup(mc->name); info->cpu_max =3D !mc->max_cpus ? 1 : mc->max_cpus; info->hotpluggable_cpus =3D mc->has_hotpluggable_cpus; + info->numa_mem_supported =3D mc->numa_mem_supported; =20 entry =3D g_malloc0(sizeof(*entry)); entry->value =3D info; --=20 2.7.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list From nobody Thu May 2 19:59:13 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 ARC-Seal: i=1; a=rsa-sha256; t=1559205203; cv=none; d=zoho.com; s=zohoarc; b=DOhMc8KpA4s2hQMF0zrmaFIIbjcfar5lXXU68ManxkEbxYijocadW5MQv8bbYQAQs5knbSE0q3tD4ApLnETSYOTZHoLzQnZH76xoA2XgeFlmpJdgOHHBjEsoiHtS+g/JFKwgZctBqpYtWbHo6AIlqOvxPYXGIYmUeclDqpKNPYM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1559205203; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=EIvg2H1mlrMHsFXnwjtYrhQ4U2p0SeTUU++ouEnaH9c=; b=EervOho09AQT4hnAo7X8F6bWHPiqs353t29UNBgdiYht02UyeTFyuh7MehD4GqT6EEPjgkydaarHv0a8pnTOVlr9zZ8C044XoY6xM1syOOefPtN8blqvZpGwCZmmUlQ5e6KFXzvTmMh9hUudEBknJmaRzulR5hR77EPNdIWUO+I= ARC-Authentication-Results: i=1; mx.zoho.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 header.from= (p=none dis=none) header.from= Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1559205203234634.0051348610167; Thu, 30 May 2019 01:33:23 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A7D17C0AD2AC; Thu, 30 May 2019 08:33:10 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 53E2E1009976; Thu, 30 May 2019 08:33:02 +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 8785C1806B11; Thu, 30 May 2019 08:32:52 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x4U8WoOr015838 for ; Thu, 30 May 2019 04:32:50 -0400 Received: by smtp.corp.redhat.com (Postfix) id 052371009976; Thu, 30 May 2019 08:32:50 +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 B5D991001E86; Thu, 30 May 2019 08:32:47 +0000 (UTC) From: Igor Mammedov To: qemu-devel@nongnu.org Date: Thu, 30 May 2019 10:33:18 +0200 Message-Id: <1559205199-233510-3-git-send-email-imammedo@redhat.com> In-Reply-To: <1559205199-233510-1-git-send-email-imammedo@redhat.com> References: <1559205199-233510-1-git-send-email-imammedo@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-loop: libvir-list@redhat.com Cc: libvir-list@redhat.com, pbonzini@redhat.com, ehabkost@redhat.com Subject: [libvirt] [PATCH v4 2/3] 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.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 30 May 2019 08:33:21 +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 performance benefits from it. The same or better results could be achieved using 'memdev' parameter. Beside of unpredictable performance, '-numa node.mem' option has other issues when it's used with combination of -mem-path + + -mem-prealloc + memdev backends (pc-dimm), breaking binding of memdev backends since mem-path/mem-prealloc are global and affect the most of RAM allocations. It's possible to make memdevs and global -mem-path/mem-prealloc to play nicely together but that will just complicate already complicated code and add unobious ways it could break on 2 different memmory allocation pathes and their combinations. Instead of it, consolidate all guest RAM allocation over memdev which still allows to create fake NUMA configurations if desired and leaves one simplifyed code path to consider when it comes to guest RAM allocation. To achieve desired simplification 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). Later down the road that will allow to consolidate means of how guest RAM is allocated and would permit us to clean up quite a bit memory allocations and numa code, leaving only 'memdev' implementation in place. Signed-off-by: Igor Mammedov --- Notes: v4: * fix up documentation to mention where users should look to check if -numa node.mem is supported numa.c | 2 ++ qemu-deprecated.texi | 16 ++++++++++++++++ 2 files changed, 18 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 50292d8..eb347f5 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -82,6 +82,22 @@ The @code{-realtime mlock=3Don|off} argument has been re= placed by the The ``-virtfs_synth'' argument is now deprecated. Please use ``-fsdev synt= h'' and ``-device virtio-9p-...'' instead. =20 +@subsection -numa node,mem=3D@var{size} (since 4.1) + +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 +RAM chunk on the host side (like bind it to a host node, setting bind poli= cy, ...), +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 a= dds +means to actualy manage node RAM on the host side. Use parameter @option{m= emdev} +with @var{memory-backend-ram} backend as an replacement for parameter @opt= ion{mem} +to achieve the same fake NUMA effect or a properly configured +@var{memory-backend-file} backend to actually benefit from NUMA configurat= ion. +In future new machine versions will not accept the option but it will still +work with old machine types. User can check QAPI schema to see if the lega= cy +option is supported by looking at MachineInfo::numa-mem-supported property. + @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 Thu May 2 19:59:13 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 ARC-Seal: i=1; a=rsa-sha256; t=1559205250; cv=none; d=zoho.com; s=zohoarc; b=RYtT+oNlvPn1aEX460RgSW95lOLFOgCZOiVML4jpWAAwb1pCiyBTN5azV4YpK19Kpa2uDUfg4KNA2dzPZPc3ClsV+hmqGr5cynV/u42Hg41/Ln/t4OEzCE8DZR3siB/3CDauQpX0xux6BRum6roAvH5/PV1oijOEB/BFgc5oeeE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1559205250; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=T1bQDjD411Yiblq52bSo7VVyxMg9YhkNl6OQprOL1ZA=; b=Jnw9nIC2hHBylDvGpVLpIrouHCgsVh9y7WNOl75pikWUzw/U8l31VBzfmf13s+eQIr8eJh/tKwpyULO/ra1el+GNsGpYqQ8zV6/5eLjlK+0gDhF2l7l5M7uJlA/2LvlBxUi1USYwTRs13pGk93jTRxWPSeMAr505lStfAuCONAg= ARC-Authentication-Results: i=1; mx.zoho.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 header.from= (p=none dis=none) header.from= Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 155920525016141.30136784028127; Thu, 30 May 2019 01:34:10 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 128B030C084B; Thu, 30 May 2019 08:33:55 +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 E809C5D9E1; Thu, 30 May 2019 08:33:52 +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 A56E4206D3; Thu, 30 May 2019 08:33:51 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x4U8WqAc015849 for ; Thu, 30 May 2019 04:32:52 -0400 Received: by smtp.corp.redhat.com (Postfix) id 9361810027C7; Thu, 30 May 2019 08:32:52 +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 4F87C1001E86; Thu, 30 May 2019 08:32:50 +0000 (UTC) From: Igor Mammedov To: qemu-devel@nongnu.org Date: Thu, 30 May 2019 10:33:19 +0200 Message-Id: <1559205199-233510-4-git-send-email-imammedo@redhat.com> In-Reply-To: <1559205199-233510-1-git-send-email-imammedo@redhat.com> References: <1559205199-233510-1-git-send-email-imammedo@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-loop: libvir-list@redhat.com Cc: libvir-list@redhat.com, pbonzini@redhat.com, ehabkost@redhat.com Subject: [libvirt] [PATCH v4 3/3] 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.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Thu, 30 May 2019 08:34:03 +0000 (UTC) Content-Type: text/plain; charset="utf-8" Implicit 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. Deprecate it, to get it out of the way so that we could consolidate guest RAM allocation using memory backends making it consistent and possibly later on transition to using memory devices instead of adhoc memory mapping for the initial RAM. Signed-off-by: Igor Mammedov --- numa.c | 3 +++ qemu-deprecated.texi | 8 ++++++++ 2 files changed, 11 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 eb347f5..c744ba9 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -98,6 +98,14 @@ In future new machine versions will not accept the optio= n but it will still work with old machine types. User can check QAPI schema to see if the lega= cy option is supported by looking at MachineInfo::numa-mem-supported property. =20 +@subsection -numa node (without memory specified) (since 4.1) + +Splitting RAM by default between NUMA nodes has the same issues as @option= {mem} +parameter described above with the difference that the role of the user pl= ays +QEMU using implicit generic or board specific splitting rule. +Use @option{memdev} with @var{memory-backend-ram} backend or @option{mem} = (if +it's supported by used machine type) 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