Re: [Qemu-devel] [RESEND][PATCH 0/3] Fix guest time drift under heavy load.

[Anthony Liguori <anthony@codemonkey.ws>]

Gleb Natapov wrote:
> On Thu, Nov 06, 2008 at 08:40:09AM -0600, Anthony Liguori wrote:
>   
>
>> Gleb: are you perhaps using a qcow2 file in conjunction with -snapshot?   
>>     
> I am using qcow2, but without -snapshot.
>   

Okay, you would still see this if your qcow2 is relatively small 
compared to the possible size it could be.

I totally believe that you could miss ticks from qcow2 metadata writing 
even with 100hz clock especially since we're using O_SYNC.  A relatively 
large write that has to extend the qcow2 file multiple times could 
conceivably block the guest for more than 10ms.  However, this is a bug 
in qcow2 IMHO.  Metadata updates should be done asynchronously and if 
they did, I bet this problem wouldn't occur.  A test against raw should 
confirm this.

>
>>> If part of qemu gets swapped out then all bets are off, and you can 
>>> easily stall for significant fractions of a second. No amount of host 
>>> high resolution time support will help you there.
>>>   
>>>       
>> Running a steady workload, you aren't going to be partially swapped.
>>
>>     
> We want to oversubscribe host as much as possible, and workload will
> vary during a lifetime of the VMs.
>   

I understand that we want guest time behave even when we're 
overcommitting the host CPU.

However, let's make sure we understand exactly what's going on such that 
we know precisely what we're fixing.  I believe the file copy benchmark 
is going to turn out to no longer produce drift with a raw image.  If 
that's the case, you'll need to find another benchmark to quantify drift.

I think the best ones are going to be intense host workload (and let's 
see how much is needed before we start drifting badly) and high guest 
frequencies with hosts that lack high resolution timers.  I think with a 
high resolution guest and no host overcommit, it should be very 
difficult to produce drift regardless of what the guest is doing.

Regards,

Anthony Liguori

> --
> 			Gleb.
>