From: "Daniel P. Berrangé" <berrange@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: "Fam Zheng" <fam.zheng@bytedance.com>,
qemu-devel@nongnu.org, "Eduardo Habkost" <eduardo@habkost.net>,
"Peter Xu" <peterx@redhat.com>,
fam@euphon.net, "Igor Mammedov" <imammedo@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Eric Blake" <eblake@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
stefanha@redhat.com
Subject: Re: [PATCH] hostmem: Add clear option to file backend
Date: Thu, 2 Mar 2023 11:44:40 +0000 [thread overview]
Message-ID: <ZACMKL5MOeD59OLl@redhat.com> (raw)
In-Reply-To: <377c3521-ffe1-074b-48ac-71fd445b3bb4@redhat.com>
On Thu, Mar 02, 2023 at 12:31:46PM +0100, David Hildenbrand wrote:
> On 02.03.23 12:09, Fam Zheng wrote:
> > This adds a memset to clear the backing memory. This is useful in the
> > case of PMEM DAX to drop dirty data, if the backing memory is handed
> > over from a previous application or firmware which didn't clean up
> > before exiting.
> >
>
> Why can't the VM manager do that instead? If you have a file that's
> certainly easily possible.
This feels conceptually similar to the case where you expose a host
block device to the guest. If that block device was previously given
to a different guest it might still have data in it. Someone needs
to take responsibility for scrubbing that data. Since that may take
a non-trivial amount of time, it is typically todo that scrubbing in
the background after the old VM is gone rather than put it into the
startup path for a new VM which would delay boot.
PMEM is blurring the boundary between memory and disk, but the tradeoff
is not so different. We know that in general merely faulting in guest
memory is quite time consuming and delays VM startup significantly as
RAM size increases. Doing the full memset can only be slower still.
For prealloc we've create complex code to fault in memory across many
threads and even that's too slow, so we're considering doing it in the
background as the VM starts up.
IIUC, this patch just puts the memset in the critical serialized path.
This will inevitably lead to a demand for improving performance by
parallelizing across threads, but we know that's too slow already,
and we cant play the background async game with memset as that's
actually changunig guest visible contents.
IOW, for large PMEM sizes, it does look compelling to do the clearing
of old data in the background outside context of QEMU VM startup to
avoid delayed startup.
I can still understand the appeal of a simple flag to set on QEMU from
a usability POV, but not sure its a good idea to encourage this usage
by mgmt apps.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2023-03-02 11:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-02 11:09 [PATCH] hostmem: Add clear option to file backend Fam Zheng
2023-03-02 11:31 ` David Hildenbrand
2023-03-02 11:37 ` [External] " Feiran Zheng
2023-03-02 11:39 ` David Hildenbrand
2023-03-02 11:48 ` Feiran Zheng
2023-03-02 11:54 ` David Hildenbrand
2023-03-02 13:31 ` Feiran Zheng
2023-03-02 11:44 ` Daniel P. Berrangé [this message]
2023-03-02 11:57 ` Feiran Zheng
2023-03-02 13:56 ` David Hildenbrand
2023-03-02 14:26 ` David Hildenbrand
2023-03-02 16:14 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZACMKL5MOeD59OLl@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=david@redhat.com \
--cc=eblake@redhat.com \
--cc=eduardo@habkost.net \
--cc=fam.zheng@bytedance.com \
--cc=fam@euphon.net \
--cc=imammedo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).