From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48854) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDPDD-0005jT-Gn for qemu-devel@nongnu.org; Thu, 09 Jul 2015 23:42:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZDPDC-0003Np-C4 for qemu-devel@nongnu.org; Thu, 09 Jul 2015 23:42:55 -0400 Date: Fri, 10 Jul 2015 05:42:48 +0200 (CEST) From: Alexandre DERUMIER Message-ID: <1233193551.9344767.1436499768115.JavaMail.zimbra@oxygem.tv> In-Reply-To: <20150709125455.GA11166@stefanha-thinkpad.redhat.com> References: <1436413678-7114-1-git-send-email-famz@redhat.com> <1436413678-7114-2-git-send-email-famz@redhat.com> <20150709125455.GA11166@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 1/3] blockjob: Introduce block_job_relax_cpu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Fam Zheng , qemu-devel , qemu-block@nongnu.org Hi Stefan, >>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 responsive= ness. I don't known if this can be compute automaticaly ? (maybe it's depend of d= isk lseek speed and cpu speed). ----- Mail original ----- De: "Stefan Hajnoczi" =C3=80: "Fam Zheng" Cc: "Kevin Wolf" , "qemu-devel" , = qemu-block@nongnu.org Envoy=C3=A9: Jeudi 9 Juillet 2015 14:54:55 Objet: Re: [Qemu-devel] [Qemu-block] [PATCH 1/3] blockjob: Introduce=09bloc= k_job_relax_cpu On Thu, Jul 09, 2015 at 11:47:56AM +0800, Fam Zheng wrote:=20 > block_job_sleep_ns is called by block job coroutines to yield the=20 > execution to VCPU threads and monitor etc. It is pointless to sleep for= =20 > 0 or a few nanoseconds, because that equals to a "yield + enter" with no= =20 > intermission in between (the timer fires immediately in the same=20 > iteration of event loop), which means other code still doesn't get a=20 > fair share of main loop / BQL.=20 >=20 > Introduce block_job_relax_cpu which will at least for=20 > BLOCK_JOB_RELAX_CPU_NS. Existing block_job_sleep_ns(job, 0) callers can= =20 > be replaced by this later.=20 >=20 > Reported-by: Alexandre DERUMIER =20 > Signed-off-by: Fam Zheng =20 > ---=20 > include/block/blockjob.h | 16 ++++++++++++++++=20 > 1 file changed, 16 insertions(+)=20 >=20 > diff --git a/include/block/blockjob.h b/include/block/blockjob.h=20 > index 57d8ef1..53ac4f4 100644=20 > --- a/include/block/blockjob.h=20 > +++ b/include/block/blockjob.h=20 > @@ -157,6 +157,22 @@ void *block_job_create(const BlockJobDriver *driver,= BlockDriverState *bs,=20 > */=20 > void block_job_sleep_ns(BlockJob *job, QEMUClockType type, int64_t ns);= =20 >=20 > +#define BLOCK_JOB_RELAX_CPU_NS 10000000L=20 By the way, why did you choose 10 milliseconds? That is quite long.=20 If this function is called once per 10 ms disk I/O operations then we=20 lose 50% utilization. 1 ms or less would be reasonable.=20 > +=20 > +/**=20 > + * block_job_relax_cpu:=20 > + * @job: The job that calls the function.=20 > + *=20 > + * Sleep a little to avoid intensive cpu time occupation. Block jobs sho= uld=20 > + * call this or block_job_sleep_ns (for more precision, but note that 0 = ns is=20 > + * usually not enought) periodically, otherwise the QMP and VCPU could s= tarve=20 s/enought/enough/=20 > + * on CPU and/or BQL.=20 > + */=20 > +static inline void block_job_relax_cpu(BlockJob *job)=20 coroutine_fn is missing.=20