From: Chongyun Wu <wucy11@chinatelecom.cn>
To: Hyman Huang <huangy81@chinatelecom.cn>, qemu-devel@nongnu.org
Cc: tugy@chinatelecom.cn, "David Hildenbrand" <david@redhat.com>,
yuanmh12@chinatelecom.cn, "Juan Quintela" <quintela@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Peter Xu" <peterx@redhat.com>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
yubin1@chinatelecom.cn, dengpc12@chinatelecom.cn,
"Paolo Bonzini" <pbonzini@redhat.com>,
baiyw2@chinatelecom.cn
Subject: Re: [PATCH v1 1/5] kvm,memory: Optimize dirty page collection for dirty ring
Date: Wed, 23 Mar 2022 19:06:39 +0800 [thread overview]
Message-ID: <f7b468f9-5e7a-fc56-49b0-2b571ac14fbb@chinatelecom.cn> (raw)
In-Reply-To: <70f26e05-1db7-2bb4-9b8d-8dc6869c7256@chinatelecom.cn>
Thank you very much for your review comments.
on 3/23/2022 12:59 PM, Hyman Huang wrote:
>
>
> 在 2022/3/23 11:18, wucy11@chinatelecom.cn 写道:
>> From: Chongyun Wu <wucy11@chinatelecom.cn>
>>
>> When log_sync_global of dirty ring is called, it will collect
>> dirty pages on all cpus, including all dirty pages on memslot,
>> so when memory_region_sync_dirty_bitmap collects dirty pages
>> from KVM, this interface needs to be called once, instead of
>> traversing every dirty page. Each memslot is called once,
>> which is meaningless and time-consuming. So only need to call
>> log_sync_global once in memory_region_sync_dirty_bitmap.
>>
>> Signed-off-by: Chongyun Wu <wucy11@chinatelecom.cn>
>> ---
>> softmmu/memory.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/softmmu/memory.c b/softmmu/memory.c
>> index 8060c6d..46c3ff9 100644
>> --- a/softmmu/memory.c
>> +++ b/softmmu/memory.c
>> @@ -2184,6 +2184,12 @@ static void
>> memory_region_sync_dirty_bitmap(MemoryRegion *mr)
>> */
>> listener->log_sync_global(listener);
>> trace_memory_region_sync_dirty(mr ? mr->name : "(all)",
>> listener->name, 1);
>> + /*
>> + * The log_sync_global of the dirty ring will collect the dirty
>> + * pages of all memslots at one time, so there is no need to
>> + * call log_sync_global once when traversing each memslot.
>> + */
>> + break;
> To the code logic itself, if a listener does not implement the log_sync_global
> callback, it never go there. If not, it should not break because we never know
> which callback is what dirty ring want.
> IMHO, maybe the modification should remove from the common logic and implemented
> somewhere else, i havn't think it through yet.
Yes, you are right. It may be more reasonable to move the modification to
kvm_set_phys_mem. In kvm_set_phys_mem, kvm_dirty_ring_reap_locked is called once
for all memslots marked with dirty pages. This interface will collect dirty
pages of all memslots, so there is a problem of repeated calls, so it is may be
more reasonable to optimize them here. I will modify it in the next version.
>> }
>> }
>> }
>
--
Best Regard,
Chongyun Wu
next prev parent reply other threads:[~2022-03-23 11:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-23 3:18 [PATCH v1 0/5] Dirty ring and auto converge optimization wucy11
2022-03-23 3:18 ` [PATCH v1 1/5] kvm, memory: Optimize dirty page collection for dirty ring wucy11
2022-03-23 4:59 ` [PATCH v1 1/5] kvm,memory: " Hyman Huang
2022-03-23 11:06 ` Chongyun Wu [this message]
2022-03-23 3:18 ` [PATCH v1 2/5] kvm: Dynamically adjust the rate of dirty ring reaper thread wucy11
2022-03-23 3:18 ` [PATCH v1 3/5] kvm: Dirty ring autoconverge optmization for kvm_cpu_synchronize_kick_all wucy11
2022-03-23 3:18 ` [PATCH v1 4/5] kvm: Introduce a dirty rate calculation method based on dirty ring wucy11
2022-03-23 3:18 ` [PATCH v1 5/5] migration: Calculate the appropriate throttle for autoconverge wucy11
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=f7b468f9-5e7a-fc56-49b0-2b571ac14fbb@chinatelecom.cn \
--to=wucy11@chinatelecom.cn \
--cc=baiyw2@chinatelecom.cn \
--cc=david@redhat.com \
--cc=dengpc12@chinatelecom.cn \
--cc=dgilbert@redhat.com \
--cc=f4bug@amsat.org \
--cc=huangy81@chinatelecom.cn \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=richard.henderson@linaro.org \
--cc=tugy@chinatelecom.cn \
--cc=yuanmh12@chinatelecom.cn \
--cc=yubin1@chinatelecom.cn \
/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.