qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: qemu-devel@nongnu.org
Cc: David Hildenbrand <david@redhat.com>,
	Juan Quintela <quintela@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Peter Xu <peterx@redhat.com>,
	Andrey Gruzdev <andrey.gruzdev@virtuozzo.com>
Subject: [PATCH v1 5/5] migration/ram: Optimize ram_write_tracking_start() for RamDiscardManager
Date: Thu,  5 Jan 2023 13:45:28 +0100	[thread overview]
Message-ID: <20230105124528.93813-6-david@redhat.com> (raw)
In-Reply-To: <20230105124528.93813-1-david@redhat.com>

ram_block_populate_read() already optimizes for RamDiscardManager.
However, ram_write_tracking_start() will still try protecting discarded
memory ranges.

Let's optimize, because discarded ranges don't map any pages and

(1) For anonymous memory, trying to protect using uffd-wp without a mapped
    page is ignored by the kernel and consequently a NOP.

(2) For shared/file-backed memory, we will fill present page tables in the
    range with PTE markers. However, we will even allocate page tables
    just to fill them with unnecessary PTE markers and effectively
    waste memory.

So let's exclude these ranges, just like ram_block_populate_read()
already does.

Signed-off-by: David Hildenbrand <david@redhat.com>
---
 migration/ram.c | 36 ++++++++++++++++++++++++++++++++++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 73a443f683..50ee1fa147 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -1865,6 +1865,39 @@ void ram_write_tracking_prepare(void)
     }
 }
 
+static inline int uffd_protect_section(MemoryRegionSection *section,
+                                       void *opaque)
+{
+    const hwaddr size = int128_get64(section->size);
+    const hwaddr offset = section->offset_within_region;
+    RAMBlock *rb = section->mr->ram_block;
+    int uffd_fd = (uintptr_t)opaque;
+
+    return uffd_change_protection(uffd_fd, rb->host + offset, size, true,
+                                  false);
+}
+
+static int ram_block_uffd_protect(RAMBlock *rb, int uffd_fd)
+{
+    assert(rb->flags & RAM_UF_WRITEPROTECT);
+
+    /* See ram_block_populate_read() */
+    if (rb->mr && memory_region_has_ram_discard_manager(rb->mr)) {
+        RamDiscardManager *rdm = memory_region_get_ram_discard_manager(rb->mr);
+        MemoryRegionSection section = {
+            .mr = rb->mr,
+            .offset_within_region = 0,
+            .size = rb->mr->size,
+        };
+
+        return ram_discard_manager_replay_populated(rdm, &section,
+                                                    uffd_protect_section,
+                                                    (void *)(uintptr_t)uffd_fd);
+    }
+    return uffd_change_protection(uffd_fd, rb->host,
+                                  rb->used_length, true, false);
+}
+
 /*
  * ram_write_tracking_start: start UFFD-WP memory tracking
  *
@@ -1900,8 +1933,7 @@ int ram_write_tracking_start(void)
         memory_region_ref(block->mr);
 
         /* Apply UFFD write protection to the block memory range */
-        if (uffd_change_protection(rs->uffdio_fd, block->host,
-                                   block->used_length, true, false)) {
+        if (ram_block_uffd_protect(block, uffd_fd)) {
             goto fail;
         }
 
-- 
2.39.0



  parent reply	other threads:[~2023-01-05 12:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-05 12:45 [PATCH v1 0/5] migration/ram: background snapshot fixes and optimiations David Hildenbrand
2023-01-05 12:45 ` [PATCH v1 1/5] migration/ram: Fix populate_read_range() David Hildenbrand
2023-02-02 11:15   ` Juan Quintela
2023-01-05 12:45 ` [PATCH v1 2/5] migration/ram: Fix error handling in ram_write_tracking_start() David Hildenbrand
2023-02-02 11:16   ` Juan Quintela
2023-01-05 12:45 ` [PATCH v1 3/5] migration/ram: Don't explicitly unprotect when unregistering uffd-wp David Hildenbrand
2023-02-02 11:17   ` Juan Quintela
2023-01-05 12:45 ` [PATCH v1 4/5] migration/ram: Rely on used_length for uffd_change_protection() David Hildenbrand
2023-02-02 11:18   ` Juan Quintela
2023-01-05 12:45 ` David Hildenbrand [this message]
2023-02-02 11:20   ` [PATCH v1 5/5] migration/ram: Optimize ram_write_tracking_start() for RamDiscardManager Juan Quintela
2023-01-05 21:11 ` [PATCH v1 0/5] migration/ram: background snapshot fixes and optimiations Peter Xu
2023-01-09  8:37   ` David Hildenbrand
2023-01-23 14:27 ` David Hildenbrand
2023-02-02 11:21   ` Juan Quintela

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=20230105124528.93813-6-david@redhat.com \
    --to=david@redhat.com \
    --cc=andrey.gruzdev@virtuozzo.com \
    --cc=dgilbert@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@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).