On Wed, Jul 15, 2015 at 06:32:54PM +0800, Fam Zheng wrote: > On Tue, 07/14 13:31, Stefan Hajnoczi wrote: > > On Fri, Jul 10, 2015 at 05:42:48AM +0200, Alexandre DERUMIER wrote: > > > >>By the way, why did you choose 10 milliseconds? That is quite long. > > > >> > > > >>If this function is called once per 10 ms disk I/O operations then we > > > >>lose 50% utilization. 1 ms or less would be reasonable. > > > > > > From my tests, 1ms is not enough, It still hanging in guest or qmp > > > queries. > > > 10ms give me optimal balance between bitmap scan speed and guest > > > responsiveness. > > > > Then I don't fully understand the bug. > > > > Fam: can you explain why 1ms isn't enough? > > In Alexandre's case, I suppose it's because the lseek is so slow that sleeping > for 1ms would still let mirror coroutine to occupy, say, 90% of CPU time, so > guest IO stutters. Perhaps we could move lseek to thread pool in the future.
Right, that's the real problem here. If lseek is done in a worker thread than the coroutine yields in the meantime and the responsiveness problem is solved. This sounds like an important fix in the early 2.5 release cycle.
pgpWzrqa3oBVa.pgp
Description: PGP signature
