From nobody Wed May 15 13:13:23 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 63.128.21.124 as permitted sender) client-ip=63.128.21.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 63.128.21.124 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=1606730801; cv=none; d=zohomail.com; s=zohoarc; b=PfmlVu42588uW414nhvtNjZuloT7FFdqayjwaLjOQSFZC34jinmgpv2a0//oFLnEXJtlHDR7fUuYIfV91A8fgT/gQay/jlKnF1VieTOXHjJOmvOXBsaMx1UpjpLP981/OQfbXXduGoyPm+a8/lg3NlawYSbpig8iTA0py6hj7Pc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1606730801; h=Content-Type:Content-Transfer-Encoding:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=IYw5K9dQOdkFNzlto29HN+l3xZNJv5U4fG8VQnlmtew=; b=g7wClSaJcR6IbTMSXIdTCVC/+JaUvSYKG6IZ2JnAxKhflnb8tW1mRMmfRY1khQ4DvFWlaKt5UchCOWv9rOIpkhoTxLlzhwoLXU8Xx2COU3WPWcjzAB9C5VwyQ4SHWZLPqngyKOK5UmF6pI4XhMxi5e2v5aYTar2vKNLxBiQUBmU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 63.128.21.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.zohomail.com with SMTPS id 1606730801713457.33679024128503; Mon, 30 Nov 2020 02:06:41 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-534-ncUW72_bMYmFZMI-nZXp-g-1; Mon, 30 Nov 2020 05:06:36 -0500 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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id 91C12802B73; Mon, 30 Nov 2020 10:06:29 +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 2EAF65D6AB; Mon, 30 Nov 2020 10:06:28 +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 139484BB7B; Mon, 30 Nov 2020 10:06:25 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 0AUA6NU3015742 for ; Mon, 30 Nov 2020 05:06:23 -0500 Received: by smtp.corp.redhat.com (Postfix) id 5BAFB5C1D0; Mon, 30 Nov 2020 10:06:23 +0000 (UTC) Received: from localhost.localdomain (unknown [10.40.194.170]) by smtp.corp.redhat.com (Postfix) with ESMTP id D16AB5C1D1 for ; Mon, 30 Nov 2020 10:06:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606730800; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=IYw5K9dQOdkFNzlto29HN+l3xZNJv5U4fG8VQnlmtew=; b=Ryg7POuFcOmxyUENo4RLD5LKt6Mop78QOlhHnsetpEtcjlcgM3j2BWy5EGs4nOHVQ/Dwh/ 5aBAkY8u1VDb7tBgpdPluwbYrpDdKbeZNnvmk32MqHSecyNxxXd1JzaC8mN89oqFeWFqZr tqlmFvDyZBjtAReEgdeQWWyBA5P3Cpk= X-MC-Unique: ncUW72_bMYmFZMI-nZXp-g-1 From: Michal Privoznik To: libvir-list@redhat.com Subject: [PATCH] qemu: Relax memory pre-allocation rules Date: Mon, 30 Nov 2020 11:06:14 +0100 Message-Id: <866ab430dc2dd84a67f9b948c90879e2ad176db0.1606730774.git.mprivozn@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-loop: libvir-list@redhat.com 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: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=libvir-list-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" Currently, we configure QEMU to prealloc memory almost by default. Well, by default for NVDIMMs, hugepages and if user asked us to (via memoryBacking ). However, there are two cases where this approach is not the best: 1) in case when guest's NVDIMM is backed by real life NVDIMM. In this case users should put into the device , like this: /dev/pmem0 Instructing QEMU to do prealloc in this case means that each page of the NVDIMM is "touched" (the first byte is read and written back - see QEMU commit v2.9.0-rc1~26^2) which cripples device wear. 2) if free-page-reporting is turned on. While the free-page-reporting feature might not have a catchy or obvious name, when enabled it instructs KVM and subsequently QEMU to free pages no longer used by guest resulting in smaller memory footprint. And preallocating whole memory goes against this. The BZ comment 11 mentions another, third case 'virtio-mem' but that is not implemented in libvirt, yet. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=3D1894053 Signed-off-by: Michal Privoznik --- src/qemu/qemu_command.c | 11 +++++++++-- .../memory-hotplug-nvdimm-pmem.x86_64-latest.args | 2 +- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 479bcc0b0c..3df8b5ac76 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -2977,7 +2977,11 @@ qemuBuildMemoryBackendProps(virJSONValuePtr *backend= Props, if (discard =3D=3D VIR_TRISTATE_BOOL_ABSENT) discard =3D def->mem.discard; =20 - if (def->mem.allocation =3D=3D VIR_DOMAIN_MEMORY_ALLOCATION_IMMEDIATE) + /* The whole point of free_page_reporting is that as soon as guest fre= es + * any memory it is freed in the host too. Prealloc doesn't make much = sense + * then. */ + if (def->mem.allocation =3D=3D VIR_DOMAIN_MEMORY_ALLOCATION_IMMEDIATE = && + def->memballoon->free_page_reporting !=3D VIR_TRISTATE_SWITCH_ON) prealloc =3D true; =20 if (virDomainNumatuneGetMode(def->numa, mem->targetNode, &mode) < 0 && @@ -3064,7 +3068,10 @@ qemuBuildMemoryBackendProps(virJSONValuePtr *backend= Props, =20 if (mem->nvdimmPath) { memPath =3D g_strdup(mem->nvdimmPath); - prealloc =3D true; + /* If the NVDIMM is a real device then there's nothing to prea= lloc. + * If anyhing, we would be only wearing off the device. */ + if (!mem->nvdimmPmem) + prealloc =3D true; } else if (useHugepage) { if (qemuGetDomainHupageMemPath(priv->driver, def, pagesize, &m= emPath) < 0) return -1; diff --git a/tests/qemuxml2argvdata/memory-hotplug-nvdimm-pmem.x86_64-lates= t.args b/tests/qemuxml2argvdata/memory-hotplug-nvdimm-pmem.x86_64-latest.ar= gs index cac02a6f6d..fb4ae4b518 100644 --- a/tests/qemuxml2argvdata/memory-hotplug-nvdimm-pmem.x86_64-latest.args +++ b/tests/qemuxml2argvdata/memory-hotplug-nvdimm-pmem.x86_64-latest.args @@ -20,7 +20,7 @@ file=3D/tmp/lib/domain--1-QEMUGuest1/master-key.aes \ -object memory-backend-ram,id=3Dram-node0,size=3D224395264 \ -numa node,nodeid=3D0,cpus=3D0-1,memdev=3Dram-node0 \ -object memory-backend-file,id=3Dmemnvdimm0,mem-path=3D/tmp/nvdimm,share= =3Dno,\ -prealloc=3Dyes,size=3D536870912,pmem=3Dyes \ +size=3D536870912,pmem=3Dyes \ -device nvdimm,node=3D0,memdev=3Dmemnvdimm0,id=3Dnvdimm0,slot=3D0 \ -uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \ -display none \ --=20 2.26.2