Re: [Qemu-devel] [PATCH COLO-Frame v15 00/38] COarse-grain LOck-stepping(COLO) Virtual Machines for Non-stop Service (FT)

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Hailiang Zhang (zhang.zhanghailiang@huawei.com) wrote:
> On 2016/2/29 17:47, Dr. David Alan Gilbert wrote:
> >* Hailiang Zhang (zhang.zhanghailiang@huawei.com) wrote:
> >>On 2016/2/27 0:36, Dr. David Alan Gilbert wrote:
> >>>* Dr. David Alan Gilbert (dgilbert@redhat.com) wrote:

> >I've got a patch where I've tried to multithread the flush - it's made it a little
> >faster, but not as much as I hoped (~20ms down to ~16ms using 4 cores)
> >
> 
> Hmm, that seems to be a good idea, after switch to COLO (hybrid) mode, in most cases,
> we will get much more dirtied pages than the periodic mode, because the delay time
> between two checkpoints is usually longer.
> The multi-thread flushing way may gain much more in that case, but i doubt, in some
> bad case, users still can't bear the pause time.
> 
> Actually, we have thought about this problem for a long time,
> In our early test based on Kernel COLO-proxy, we can easily got more than
> one seconds' flushing time, IMHO, uses can't bear the long pausing time of VM if they
> choose to use COLO.

Yes, that's just too long; although only solving the 'flushing' time isn't enough in those
cases, because the same cases will probably need to transfer lots of RAM over the wire as well.

> We have designed another scenario which based on userfault's page-miss capability.
> The base idea is to convert the flushing action to marking action, the flush action
> will be processed during SVM's running time. For now it is only an idea,
> we'd like to verify the idea first. (I'm not quite sure if userfaults' page-miss
> feature is good performance designed, while we use it to mark one page to be MISS a time).

Yes, it's a different trade off, slower execution, but no flush time.

Dave

> 
> 
> Thanks,
> Hailiang
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK