From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58695) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDSVC-0003Wx-JV for qemu-devel@nongnu.org; Fri, 10 Jul 2015 03:13:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZDSVB-0002Lf-D0 for qemu-devel@nongnu.org; Fri, 10 Jul 2015 03:13:42 -0400 Date: Fri, 10 Jul 2015 15:13:33 +0800 From: Fam Zheng Message-ID: <20150710071333.GA16297@ad.nay.redhat.com> References: <1436413678-7114-1-git-send-email-famz@redhat.com> <20150709130208.GD11166@stefanha-thinkpad.redhat.com> <20150710064350.GG31230@ad.nay.redhat.com> <278695903.9362838.1436511286250.JavaMail.zimbra@oxygem.tv> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <278695903.9362838.1436511286250.JavaMail.zimbra@oxygem.tv> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 0/3] mirror: Fix guest responsiveness during bitmap scan List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexandre DERUMIER Cc: Kevin Wolf , Stefan Hajnoczi , qemu-devel , qemu-block@nongnu.org On Fri, 07/10 08:54, Alexandre DERUMIER wrote: > >>Thinking about this again, I doubt > >>that lengthening the duration with a hardcoded value benifits everyon= e; and > >>before Alexandre's reply on old server/slow disks >=20 > With 1ms sleep, I can reproduce the hang 100% with a fast cpu (xeon e5 = v3 3,1ghz) and source raw file on nfs. Does it completely hang? I can't reproduce this with my machine mirroring= from nfs to local: the guest runs smoothly. What does "perf top" show? Fam >=20 >=20 > ----- Mail original ----- > De: "Fam Zheng" > =C0: "Stefan Hajnoczi" > Cc: "Kevin Wolf" , "qemu-devel" , qemu-block@nongnu.org > Envoy=E9: Vendredi 10 Juillet 2015 08:43:50 > Objet: Re: [Qemu-devel] [Qemu-block] [PATCH 0/3] mirror: Fix guest resp= onsiveness during bitmap scan >=20 > On Thu, 07/09 14:02, Stefan Hajnoczi wrote:=20 > > This patch only converts the mirror block job to use the new relax=20 > > function. The other block jobs (stream, backup, commit) are still usi= ng=20 > > a 0 ns delay and are therefore broken. They should probably be=20 > > converted in the same series.=20 >=20 > That's because they all can be perfectly mitigated by setting a reasona= ble=20 > "speed" that matchs the host horsepower. Thinking about this again, I d= oubt=20 > that lengthening the duration with a hardcoded value benifits everyone;= and=20 > before Alexandre's reply on old server/slow disks, I don't recall any r= eport,=20 > because the coroutines would already yield often enough, when waiting f= or IO to=20 > complete. So I am not sure whether they're broken in practice.=20 >=20 > Fam=20