From nobody Wed May 14 13:22:49 2025
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 1524215398452246.8765987909261;
Fri, 20 Apr 2018 02:09:58 -0700 (PDT)
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 0381581DEB;
Fri, 20 Apr 2018 09:09:57 +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 C893560A9D;
Fri, 20 Apr 2018 09:09:56 +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 7B71365D15;
Fri, 20 Apr 2018 09:09:56 +0000 (UTC)
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com
[10.11.54.5])
by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
id w3K99hD7006814 for ;
Fri, 20 Apr 2018 05:09:44 -0400
Received: by smtp.corp.redhat.com (Postfix)
id D5DB5AFD4A; Fri, 20 Apr 2018 09:09:43 +0000 (UTC)
Received: from moe.brq.redhat.com (unknown [10.43.2.192])
by smtp.corp.redhat.com (Postfix) with ESMTP id 3D794AB5BC;
Fri, 20 Apr 2018 09:09:43 +0000 (UTC)
From: Michal Privoznik
To: libvir-list@redhat.com
Date: Fri, 20 Apr 2018 11:09:31 +0200
Message-Id:
In-Reply-To:
References:
In-Reply-To:
References:
X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5
X-loop: libvir-list@redhat.com
Cc: zack.cornelius@kove.net, ehabkost@redhat.com
Subject: [libvirt] [PATCH v4 5/5] qemu: Introduce memoryBacking/discard
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.25]);
Fri, 20 Apr 2018 09:09:57 +0000 (UTC)
X-ZohoMail: RSF_0 Z_629925259 SPT_0
Content-Type: text/plain; charset="utf-8"
https://bugzilla.redhat.com/show_bug.cgi?id=3D1480668
QEMU has this new feature memory-backend-file.discard-data=3Dyes
which is a nifty optimization. Basically, when qemu is quitting
or on memory hotplug it calls munmap() and close() on the file
that is backing the memory. However, this does not mean kernel
won't stop touching that part of memory. It still might. With
this feature enabled we tell kernel: "we don't need this memory
nor data stored in it". This makes kernel drop the memory
immediately without trying to sync memory with the mapped file.
Unfortunately, this cannot be turned on by default because we
can't be sure when users really don't care about what happens to
data after qemu dies. So it has to be opt-in. As usual, there are
three places where one can configure memory attributes. This
patch adds the feature to all of them.
Signed-off-by: Michal Privoznik
---
docs/formatdomain.html.in | 34 ++++++++++++++++++++++--
docs/schemas/cputypes.rng | 5 ++++
docs/schemas/domaincommon.rng | 10 +++++++
src/conf/domain_conf.c | 39 ++++++++++++++++++++++++=
++--
src/conf/domain_conf.h | 3 +++
src/conf/numa_conf.c | 27 +++++++++++++++++++
src/conf/numa_conf.h | 3 +++
src/libvirt_private.syms | 1 +
src/qemu/qemu_command.c | 27 ++++++++++++++++---
tests/qemuxml2argvdata/hugepages-pages7.args | 3 ++-
tests/qemuxml2argvdata/hugepages-pages7.xml | 4 +--
tests/qemuxml2argvtest.c | 3 ++-
12 files changed, 148 insertions(+), 11 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index ada0df227f..ea9d77bd18 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -1016,6 +1016,7 @@
<source type=3D"file|anonymous"/>
<access mode=3D"shared|private"/>
<allocation mode=3D"immediate|ondemand"/>
+ <discard/>
</memoryBacking>
...
</domain>
@@ -1070,6 +1071,14 @@
numa node by memAccess
allocation
Specify when allocate the memory
+
discard
+
When set and supported by hypervisor the memory
+ content is discarded just before guest shuts down (or
+ when DIMM module is unplugged). Please note that this is
+ just an optimization and is not guaranteed to work in
+ all cases (e.g. when hypervisor crashes).
+ Since 4.3.0 (QEMU/KVM only)
+
=20
=20
@@ -1608,7 +1617,7 @@
<cpu>
...
<numa>
- <cell id=3D'0' cpus=3D'0-3' memory=3D'512000' unit=3D'KiB'/>
+ <cell id=3D'0' cpus=3D'0-3' memory=3D'512000' unit=3D'KiB' discard=
=3D'yes'/>
<cell id=3D'1' cpus=3D'4-7' memory=3D'512000' unit=3D'KiB' memAcces=
s=3D'shared'/>
</numa>
...
@@ -1634,6 +1643,13 @@
memAccess can control whether the memory is to be
mapped as "shared" or "private". This is valid only for
hugepages-backed memory and nvdimm modules.
+
+ Each cell element can have an optional
+ discard attribute which fine tunes the discard
+ feature for given numa node as described under
+ Memory Backing.
+ Accepted values are yes and no.
+ Since 4.3.0
+ An optional attribute discard
+ (since 4.3.0) that provides
+ capability to fine tune discard of data on per module
+ basis. Accepted values are yes and
+ no. The feature is described here:
+ Memory Backing.
+ This attribute is allowed only for
+ model=3D'dimm'.
+