|
From: | Kunkun Jiang |
Subject: | Re: [PATCH v3 3/3] migration/ram: Optimize ram_save_host_page() |
Date: | Tue, 9 Mar 2021 20:47:00 +0800 |
User-agent: | Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 |
Hi, On 2021/3/9 5:36, Peter Xu wrote:
On Mon, Mar 08, 2021 at 09:58:02PM +0800, Kunkun Jiang wrote:Hi, On 2021/3/5 22:30, Peter Xu wrote:On Fri, Mar 05, 2021 at 03:50:35PM +0800, Kunkun Jiang wrote:Starting from pss->page, ram_save_host_page() will check every page and send the dirty pages up to the end of the current host page or the boundary of used_length of the block. If the host page size is a huge page, the step "check" will take a lot of time. This will improve performance to use migration_bitmap_find_dirty().Is there any measurement done?I tested it on Kunpeng 920. VM params: 1U 4G( page size 1G). The time of ram_save_host_page() in the last round of ram saving: before optimize: 9250us after optimize: 34usLooks like an idle VM, but still this is a great improvement. Would you mind add this into the commit message too?
Ok, I will add it in the next version.😉
Both versions are fine to me. This version may make the final code slightly cleaner, I think.This looks like an optimization, but to me it seems to have changed a lot context that it doesn't need to... Do you think it'll also work to just look up dirty again and update pss->page properly if migration_bitmap_clear_dirty() returned zero? Thanks,This just inverted the body of the loop, suggested by @David Edmondson. Here is the v2[1]. Do you mean to change it like this? [1]: 20210301082132.1107-4-jiangkunkun@huawei.com/">http://patchwork.ozlabs.org/project/qemu-devel/patch/20210301082132.1107-4-jiangkunkun@huawei.com/I see, then it's okay - But indeed I still prefer your previous version. :) Thanks,
Thanks, Kunkun Jiang
[Prev in Thread] | Current Thread | [Next in Thread] |