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