From: David Hildenbrand <david@redhat.com>
To: Peng Liang <liangpeng10@huawei.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: akpm@linux-foundation.org, hughd@google.com,
xiexiangyou@huawei.com, zhengchuan@huawei.com,
wanghao232@huawei.com,
"dgilbert@redhat.com" <dgilbert@redhat.com>
Subject: Re: [RFC 0/1] memfd: Support mapping to zero page on reading
Date: Tue, 4 Jan 2022 15:44:55 +0100 [thread overview]
Message-ID: <01e42346-5b4d-8ccc-d485-5d866da7cf8d@redhat.com> (raw)
In-Reply-To: <20211222123400.1659635-1-liangpeng10@huawei.com>
On 22.12.21 13:33, Peng Liang wrote:
> Hi all,
>
> Recently we are working on implementing CRIU [1] for QEMU based on
> Steven's work [2]. It will use memfd to allocate guest memory in order
> to restore (inherit) it in the new QEMU process. However, memfd will
> allocate a new page for reading while anonymous memory will map to zero
> page for reading. For QEMU, memfd may cause that all memory are
> allocated during the migration because QEMU will read all pages in
> migration. It may lead to OOM if over-committed memory is enabled,
> which is usually enabled in public cloud.
Hi,
it's the exact same problem as if just migrating a VM after inflating
the balloon, or after reporting free memory to the hypervisor via
virtio-balloon free page reporting.
Even populating the shared zero page still wastes CPU time and more
importantly memory for page tables. Further, you'll end up reading the
whole page to discover that you just populated the shared zeropage, far
from optimal. Instead of doing that dance, just check if there is
something worth reading at all.
You could simply sense if a page is actually populated before going
ahead and reading it for migration. I actually discussed that recently
with Dave Gilbert.
For anonymous memory it's pretty straight forward via
/proc/self/pagemap. For files you can use lseek.
https://lkml.kernel.org/r/20210923064618.157046-2-tiberiu.georgescu@nutanix.com
Contains some details. There was a discussion to eventually have a
better bulk interface for it if it's necessary for performance.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2022-01-04 14:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-22 12:33 [RFC 0/1] memfd: Support mapping to zero page on reading Peng Liang
2021-12-22 12:34 ` [RFC 1/1] " Peng Liang
2022-01-04 14:44 ` David Hildenbrand [this message]
2022-01-12 2:30 ` [RFC 0/1] " Hugh Dickins
2022-01-12 3:33 ` Yang Shi
2022-01-12 5:02 ` Hugh Dickins
2022-01-12 4:32 ` Matthew Wilcox
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=01e42346-5b4d-8ccc-d485-5d866da7cf8d@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dgilbert@redhat.com \
--cc=hughd@google.com \
--cc=liangpeng10@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=wanghao232@huawei.com \
--cc=xiexiangyou@huawei.com \
--cc=zhengchuan@huawei.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).