qemu-devel
[Top][All Lists]
Advanced

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

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


From: Dor Laor
Subject: Re: [Qemu-devel] [RESEND][PATCH 0/3] Fix guest time drift under heavy load.
Date: Wed, 12 Nov 2008 14:38:57 +0200
User-agent: Thunderbird 2.0.0.16 (X11/20080723)

Glauber Costa wrote:
On Wed, Nov 12, 2008 at 9:42 AM, Gleb Natapov <address@hidden> wrote:
  
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.
    

It might well be a stupid idea, (would have to benchmark it), but the
other day it occurred to me
that we could keep timekeeping in a separate _process_, with a shm
area, doing timekeeping
for all running guests.

  
The problem is that the right vcpu should be preempted in order us injecting time irq into it.
It will introduce latency (signal/IPI).
This is why the in-kernel pit performs better/ more accurate.

What we can do is add a kernel interface to schedule a timer on a specific cpu for preempting the vcpu.
The problem such interface is a bit awkward and Avi feels it's beginning to be too complex.

So either we fix it using Gleb's set_irq ack method or just fix the RTC using Andrzej suggestion for RTC irq
status bit.

reply via email to

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