[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 2/3] migration/ram: Reduce unnecessary rate limiting
From: |
Peter Xu |
Subject: |
Re: [PATCH v3 2/3] migration/ram: Reduce unnecessary rate limiting |
Date: |
Mon, 8 Mar 2021 16:12:55 -0500 |
On Mon, Mar 08, 2021 at 06:34:58PM +0800, Kunkun Jiang wrote:
> Hi,
>
> On 2021/3/5 22:22, Peter Xu wrote:
> > Kunkun,
> >
> > On Fri, Mar 05, 2021 at 03:50:34PM +0800, Kunkun Jiang wrote:
> > > When the host page is a huge page and something is sent in the
> > > current iteration, the migration_rate_limit() should be executed.
> > > If not, this function can be omitted to save time.
> > >
> > > Rename tmppages to pages_this_iteration to express its meaning
> > > more clearly.
> > >
> > > Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
> > > Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
> > > ---
> > > migration/ram.c | 21 ++++++++++++++-------
> > > 1 file changed, 14 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/migration/ram.c b/migration/ram.c
> > > index a168da5cdd..9fc5b2997c 100644
> > > --- a/migration/ram.c
> > > +++ b/migration/ram.c
> > > @@ -1988,7 +1988,7 @@ static int ram_save_target_page(RAMState *rs,
> > > PageSearchStatus *pss,
> > > static int ram_save_host_page(RAMState *rs, PageSearchStatus *pss,
> > > bool last_stage)
> > > {
> > > - int tmppages, pages = 0;
> > > + int pages = 0;
> > > size_t pagesize_bits =
> > > qemu_ram_pagesize(pss->block) >> TARGET_PAGE_BITS;
> > > unsigned long start_page = pss->page;
> > > @@ -2000,21 +2000,28 @@ static int ram_save_host_page(RAMState *rs,
> > > PageSearchStatus *pss,
> > > }
> > > do {
> > > + int pages_this_iteration = 0;
> > > +
> > > /* Check if the page is dirty and send it if it is */
> > > if (!migration_bitmap_clear_dirty(rs, pss->block, pss->page)) {
> > > pss->page++;
> > > continue;
> > > }
> > > - tmppages = ram_save_target_page(rs, pss, last_stage);
> > > - if (tmppages < 0) {
> > > - return tmppages;
> > > + pages_this_iteration = ram_save_target_page(rs, pss, last_stage);
> > > + if (pages_this_iteration < 0) {
> > > + return pages_this_iteration;
> > > }
> > > - pages += tmppages;
> > > + pages += pages_this_iteration;
> > To me, both names are okay, it's just that the new name doesn't really
> > provide
> > a lot more new information, while it's even longer...
> >
> > Since you seem to prefer cleaning up tmppages, I'm actually thinking whether
> > it should be called as "pages" at all since ram_save_target_page() majorly
> > only
> > returns either 1 if succeeded or <0 if error. There's only one very corner
> > case of xbzrle where it can return 0 in save_xbzrle_page():
> >
> > if (encoded_len == 0) {
> > trace_save_xbzrle_page_skipping();
> > return 0;
> > }
> >
> > I think it means the page didn't change at all, then I'm also wondering
> > maybe
> > it can also return 1 showing one page migrated (though actually skipped!)
> > which
> > should still be fine for the callers, e.g., ram_find_and_save_block() who
> > will
> > finally check this "pages" value.
> >
> > So I think _maybe_ that's a nicer cleanup to change that "return 0" to
> > "return
> > 1", then another patch to make the return value to be (1) return 0 if page
> > saved, or (2) return <0 if error. Then here in ram_save_host_page()
> > tmppages
> > can be renamed to "ret" or "succeed".
> Thanks for your advice.
> change "return 0" to "return 1" would have a slight effect on
> 'rs->target_page_count += pages'
> in ram_save_iterate(). This may lead to consider more complex situations.
> What do you think of
> this?
I don't think we should change the meaning of ram_save_host_page()'s return
value, but only ram_save_target_page(); ram_save_host_page() could return >1
for huge pages. Thanks,
--
Peter Xu
[PATCH v3 2/3] migration/ram: Reduce unnecessary rate limiting, Kunkun Jiang, 2021/03/05
[PATCH v3 3/3] migration/ram: Optimize ram_save_host_page(), Kunkun Jiang, 2021/03/05