All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Chunguang Li" <lichunguang@hust.edu.cn>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: qemu-devel@nongnu.org, amit.shah@redhat.com, pbonzini@redhat.com,
	stefanha@redhat.com, quintela@redhat.com
Subject: Re: [Qemu-devel] Migration dirty bitmap: should only mark pages as dirty after they have been sent
Date: Mon, 26 Sep 2016 22:55:01 +0800 (GMT+08:00)	[thread overview]
Message-ID: <13289d.86da.15766fdf27c.Coremail.lichunguang@hust.edu.cn> (raw)
In-Reply-To: <20160926112349.GF2029@work-vm>




> -----原始邮件-----
> 发件人: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> 发送时间: 2016年9月26日 星期一
> 收件人: "Chunguang Li" <lichunguang@hust.edu.cn>
> 抄送: qemu-devel@nongnu.org, amit.shah@redhat.com, pbonzini@redhat.com, stefanha@redhat.com, quintela@redhat.com
> 主题: Re: [Qemu-devel] Migration dirty bitmap: should only mark pages as dirty after they have been sent
> 
> * Chunguang Li (lichunguang@hust.edu.cn) wrote:
> > Hi all!
> > I have some confusion about the dirty bitmap during migration. I have digged into the code. I figure out that every now and then during migration, the dirty bitmap will be grabbed from the kernel space through ioctl(KVM_GET_DIRTY_LOG), and then be used to update qemu's dirty bitmap. However I think this mechanism leads to resendness of some NON-dirty pages.
> > 
> > Take the first iteration of precopy for instance, during which all the pages will be sent. Before that during the migration setup, the ioctl(KVM_GET_DIRTY_LOG) is called once, so the kernel begins to produce the dirty bitmap from this moment. When the pages "that haven't been sent" are written, the kernel space marks them as dirty. However I don't think this is correct, because these pages will be sent during this and the next iterations with the same content (if they are not written again after they are sent). It only makes sense to mark the pages which have already been sent during one iteration as dirty when they are written.
> > 
> > 
> > Am I right about this consideration? If I am right, is there some advice to improve this?
> 
> I think you're right that this can happen; to clarify I think the
> case you're talking about is:
> 
>   Iteration 1
>     sync bitmap
>     start sending pages
>     page 'n' is modified - but hasn't been sent yet
>     page 'n' gets sent
>   Iteration 2
>     sync bitmap
>        'page n is shown as modified'
>     send page 'n' again
>

Yes,this is right the case I am talking about.
 
> So you're right that is wasteful; I guess it's more wasteful
> on big VMs with slow networks where the length of each iteration
> is large.

I think this is "very" wasteful. Assume the workload writes the pages dirty randomly within the guest address space, and the transfer speed is constant. Intuitively, I think nearly half of the dirty pages produced in Iteration 1 is not really dirty. This means the time of Iteration 2 is double of that to send only really dirty pages.

Thanks,

Chunguang

> 
> Fixing it is not easy, because you have to be really careful
> never to miss a page modification, even if the page is sent
> about the same time it's dirtied.
> 
> One way would be to sync the dirty log from the kernel
> in smaller chunks.
> 
> Dave
> 
> 
> > 
> > Thanks,
> > Chunguang Li
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK


--
Chunguang Li, Ph.D. Candidate
Wuhan National Laboratory for Optoelectronics (WNLO)
Huazhong University of Science & Technology (HUST)
Wuhan, Hubei Prov., China

  reply	other threads:[~2016-09-26 14:52 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-25  8:22 [Qemu-devel] Migration dirty bitmap: should only mark pages as dirty after they have been sent Chunguang Li
2016-09-26 11:23 ` Dr. David Alan Gilbert
2016-09-26 14:55   ` Chunguang Li [this message]
2016-09-26 18:52     ` Dr. David Alan Gilbert
2016-09-27 12:28       ` Chunguang Li
2016-09-30  5:46     ` Amit Shah
2016-09-30  8:18       ` Chunguang Li
2016-10-08  7:55       ` Chunguang Li
2016-10-14 11:15         ` Dr. David Alan Gilbert
2016-11-03  8:25           ` Chunguang Li
2016-11-03  9:59             ` Li, Liang Z
2016-11-03 10:13             ` Li, Liang Z
2016-11-04  3:07               ` Chunguang Li
2016-11-04  4:50                 ` Li, Liang Z
2016-11-04  7:03                   ` Chunguang Li
2016-11-07 13:52                   ` Chunguang Li
2016-11-07 14:17                     ` Li, Liang Z
2016-11-08  5:27                       ` Chunguang Li
2016-11-07 14:44                     ` Li, Liang Z
2016-11-08 11:05             ` Dr. David Alan Gilbert
2016-11-08 13:40               ` Chunguang Li

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=13289d.86da.15766fdf27c.Coremail.lichunguang@hust.edu.cn \
    --to=lichunguang@hust.edu.cn \
    --cc=amit.shah@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=stefanha@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 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.