From: Juan Quintela <quintela@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: "Eduardo Habkost" <ehabkost@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Pankaj Gupta" <pankaj.gupta@cloud.ionos.com>,
teawater <teawaterz@linux.alibaba.com>,
qemu-devel@nongnu.org, "Peter Xu" <peterx@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Alex Williamson" <alex.williamson@redhat.com>,
"Marek Kedzierski" <mkedzier@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Andrey Gruzdev" <andrey.gruzdev@virtuozzo.com>,
"Wei Yang" <richard.weiyang@linux.alibaba.com>
Subject: Re: [PATCH v1 9/9] migration/ram: Handle RAMBlocks with a RamDiscardManager on background snapshots
Date: Mon, 01 Nov 2021 19:35:09 +0100 [thread overview]
Message-ID: <87ee7zsp0i.fsf@secure.mitica> (raw)
In-Reply-To: <20211011175346.15499-10-david@redhat.com> (David Hildenbrand's message of "Mon, 11 Oct 2021 19:53:46 +0200")
David Hildenbrand <david@redhat.com> wrote:
> We already don't ever migrate memory that corresponds to discarded ranges
> as managed by a RamDiscardManager responsible for the mapped memory region
> of the RAMBlock.
>
> virtio-mem uses this mechanism to logically unplug parts of a RAMBlock.
> Right now, we still populate zeropages for the whole usable part of the
> RAMBlock, which is undesired because:
>
> 1. Even populating the shared zeropage will result in memory getting
> consumed for page tables.
> 2. Memory backends without a shared zeropage (like hugetlbfs and shmem)
> will populate an actual, fresh page, resulting in an unintended
> memory consumption.
>
> Discarded ("logically unplugged") parts have to remain discarded. As
> these pages are never part of the migration stream, there is no need to
> track modifications via userfaultfd WP reliably for these parts.
>
> Further, any writes to these ranges by the VM are invalid and the
> behavior is undefined.
>
> Note that Linux only supports userfaultfd WP on private anonymous memory
> for now, which usually results in the shared zeropage getting populated.
> The issue will become more relevant once userfaultfd WP supports shmem
> and hugetlb.
>
> Acked-by: Peter Xu <peterx@redhat.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
next prev parent reply other threads:[~2021-11-01 19:52 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-11 17:53 [PATCH v1 0/9] migration/ram: Optimize for virtio-mem via RamDiscardManager David Hildenbrand
2021-10-11 17:53 ` [PATCH v1 1/9] memory: Introduce replay_discarded callback for RamDiscardManager David Hildenbrand
2021-11-01 12:49 ` Juan Quintela
2021-10-11 17:53 ` [PATCH v1 2/9] virtio-mem: Implement replay_discarded RamDiscardManager callback David Hildenbrand
2021-11-01 18:10 ` Juan Quintela
2021-10-11 17:53 ` [PATCH v1 3/9] migration/ram: Don't passs RAMState to migration_clear_memory_region_dirty_bitmap_*() David Hildenbrand
2021-11-01 12:46 ` Juan Quintela
2021-10-11 17:53 ` [PATCH v1 4/9] migration/ram: Handle RAMBlocks with a RamDiscardManager on the migration source David Hildenbrand
2021-11-01 18:14 ` Juan Quintela
2021-10-11 17:53 ` [PATCH v1 5/9] virtio-mem: Drop precopy notifier David Hildenbrand
2021-11-01 18:15 ` Juan Quintela
2021-10-11 17:53 ` [PATCH v1 6/9] migration/postcopy: Handle RAMBlocks with a RamDiscardManager on the destination David Hildenbrand
2021-11-01 18:21 ` Juan Quintela
2021-10-11 17:53 ` [PATCH v1 7/9] migration: Simplify alignment and alignment checks David Hildenbrand
2021-10-14 9:33 ` Philippe Mathieu-Daudé
2021-11-01 18:27 ` Juan Quintela
2021-10-11 17:53 ` [PATCH v1 8/9] migration/ram: Factor out populating pages readable in ram_block_populate_pages() David Hildenbrand
2021-11-01 18:32 ` Juan Quintela
2021-10-11 17:53 ` [PATCH v1 9/9] migration/ram: Handle RAMBlocks with a RamDiscardManager on background snapshots David Hildenbrand
2021-11-01 18:35 ` Juan Quintela [this message]
2021-10-13 17:35 ` [PATCH v1 0/9] migration/ram: Optimize for virtio-mem via RamDiscardManager Dr. David Alan Gilbert
2021-10-14 8:43 ` David Hildenbrand
2021-10-14 8:43 ` David Hildenbrand
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=87ee7zsp0i.fsf@secure.mitica \
--to=quintela@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=andrey.gruzdev@virtuozzo.com \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=mkedzier@redhat.com \
--cc=mst@redhat.com \
--cc=pankaj.gupta@cloud.ionos.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.weiyang@linux.alibaba.com \
--cc=teawaterz@linux.alibaba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.