qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-block] [PATCH 0/3] mirror: Fix guest responsivene


From: Alexandre DERUMIER
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 0/3] mirror: Fix guest responsiveness during bitmap scan
Date: Fri, 10 Jul 2015 12:36:40 +0200 (CEST)

>>Does it completely hang? 
yes, can't ping network, and vnc console is frozen.


>>What does "perf top" show? 
I'll do test today . (I'm going to vacation this night,I'll try to send results 
before that)

----- Mail original -----
De: "Fam Zheng" <address@hidden>
À: "aderumier" <address@hidden>
Cc: "Stefan Hajnoczi" <address@hidden>, "Kevin Wolf" <address@hidden>, 
"qemu-devel" <address@hidden>, address@hidden
Envoyé: Vendredi 10 Juillet 2015 09:13:33
Objet: Re: [Qemu-devel] [Qemu-block] [PATCH 0/3] mirror: Fix guest 
responsiveness during bitmap scan

On Fri, 07/10 08:54, Alexandre DERUMIER wrote: 
> >>Thinking about this again, I doubt 
> >>that lengthening the duration with a hardcoded value benifits everyone; and 
> >>before Alexandre's reply on old server/slow disks 
> 
> 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 

> 
> 
> ----- Mail original ----- 
> De: "Fam Zheng" <address@hidden> 
> À: "Stefan Hajnoczi" <address@hidden> 
> Cc: "Kevin Wolf" <address@hidden>, "qemu-devel" <address@hidden>, 
> address@hidden 
> Envoyé: Vendredi 10 Juillet 2015 08:43:50 
> Objet: Re: [Qemu-devel] [Qemu-block] [PATCH 0/3] mirror: Fix guest 
> responsiveness during bitmap scan 
> 
> On Thu, 07/09 14:02, Stefan Hajnoczi wrote: 
> > This patch only converts the mirror block job to use the new relax 
> > function. The other block jobs (stream, backup, commit) are still using 
> > a 0 ns delay and are therefore broken. They should probably be 
> > converted in the same series. 
> 
> That's because they all can be perfectly mitigated by setting a reasonable 
> "speed" that matchs the host horsepower. Thinking about this again, I doubt 
> that lengthening the duration with a hardcoded value benifits everyone; and 
> before Alexandre's reply on old server/slow disks, I don't recall any report, 
> because the coroutines would already yield often enough, when waiting for IO 
> to 
> complete. So I am not sure whether they're broken in practice. 
> 
> Fam 



reply via email to

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