All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keqian Zhu <zhukeqian1@huawei.com>
To: <qemu-devel@nongnu.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org, Keqian Zhu <zhukeqian1@huawei.com>,
	"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
	wanghaibin.wang@huawei.com
Subject: [PATCH v2 2/2] migration: not require length align when choose fast dirty sync path
Date: Tue, 10 Mar 2020 17:17:04 +0800	[thread overview]
Message-ID: <20200310091704.42340-3-zhukeqian1@huawei.com> (raw)
In-Reply-To: <20200310091704.42340-1-zhukeqian1@huawei.com>

In commit aa777e297c84 ("cpu_physical_memory_sync_dirty_bitmap: Another
alignment fix"), ramblock length is required to align word pages when
we choose the fast dirty sync path. The reason is that "If the Ramblock
is less than 64 pages in length that long can contain bits representing
two different RAMBlocks, but the code will update the bmap belinging to
the 1st RAMBlock only while having updated the total dirty page count
for both."

This is right before commit 801110ab22be ("find_ram_offset: Align
ram_addr_t allocation on long boundaries"), which align ram_addr_t
allocation on long boundaries. So currently we wont "updated the total
dirty page count for both".

By removing the alignment constraint of length in fast path, we can always
use fast dirty sync path if start_global is aligned to word page.

Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
---
 include/exec/ram_addr.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index 8311efb7bc..57b3edf376 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -450,9 +450,8 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb,
     uint64_t num_dirty = 0;
     unsigned long *dest = rb->bmap;
 
-    /* start address and length is aligned at the start of a word? */
-    if (((word * BITS_PER_LONG) << TARGET_PAGE_BITS) == start_global &&
-        !(length & ((BITS_PER_LONG << TARGET_PAGE_BITS) - 1))) {
+    /* start address is aligned at the start of a word? */
+    if (((word * BITS_PER_LONG) << TARGET_PAGE_BITS) == start_global) {
         int k;
         int nr = BITS_TO_LONGS(length >> TARGET_PAGE_BITS);
         unsigned long * const *src;
-- 
2.19.1



      parent reply	other threads:[~2020-03-10  9:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-10  9:17 [PATCH v2 0/2] Some optimization in dirty bitmap sync Keqian Zhu
2020-03-10  9:17 ` [PATCH v2 1/2] memory: Introduce start_global variable " Keqian Zhu
2020-03-10  9:17 ` Keqian Zhu [this message]

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=20200310091704.42340-3-zhukeqian1@huawei.com \
    --to=zhukeqian1@huawei.com \
    --cc=dgilbert@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=wanghaibin.wang@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 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.