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]

* Hailiang Zhang (address@hidden) wrote:
> On 2016/2/29 17:47, Dr. David Alan Gilbert wrote:
> >* Hailiang Zhang (address@hidden) wrote:
> >>On 2016/2/27 0:36, Dr. David Alan Gilbert wrote:
> >>>* Dr. David Alan Gilbert (address@hidden) 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 / address@hidden / Manchester, UK