qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-block] [PATCH 1/3] blockjob: Introduce block_job_


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 1/3] blockjob: Introduce block_job_relax_cpu
Date: Thu, 16 Jul 2015 14:21:17 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

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.

Attachment: pgpRJDTkLaE0K.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]