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

[Gleb Natapov]

On Tue, Nov 11, 2008 at 02:17:49PM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
>> On Mon, Nov 10, 2008 at 09:46:12AM -0600, Anthony Liguori wrote:
>>   -usbdevice tablet has nothing to do with it. Qemu misses interrupt 
>> even
>> without this option and with SDL screen it misses them in bunches when
>> SDL redraws a screen. In case of vnc qemu misses interrupt because of
>> fsync() call in raw_flush(), or so my instrumentation shows.
>>   
>
> Can you give this patch a spin?
>
Doesn't compile for me. fd_pool_inuse and fd_inuse are used but not
defined.

> This introduces a bdrv_aio_flush() which will wait for all existing AIO  
> operations to complete before indicating completion.  It also fixes up  
> IDE.  Fixing up SCSI will be a little more tricky but not much.  Since  
> we now use O_DSYNC, it's unnecessary to do an fsync (or an fdatasync).
>
> Assuming you're using IDE, this should eliminate any delays from fsync.   
I am using IDE.

> SDL delays are unavoidable because it's going to come down to SDL doing  
> sychronous updates to the X server.  The proper long term solution here  
> would be to put SDL in it's own thread but I'm not too worried about  
And probably time-keeping deserves its own thread. And CPU execution
too.

> this case.  It's a good argument for timer fixups but I think it's  
> important to identify all the reasons we're losing ticks and if we can  
> do something about it, we should.
>
I completely agree that all the cases that can be fixed should be fixed,
but even if qemu itself will be perfect, it is still at mercy of scheduler
to get scheduled often enough. Qemu timers code tries to compensate missed
timer by triggering next one immediately. What I am seen with SDL is
that qemu missed ~10 timers and tries to run all of them at once without
giving CPU chance to handle any of them. As a result all but one of them
are lost.

--
                        Gleb.