|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 188.8.131.52 (X11/20080723)|
Glauber Costa wrote:
The problem is that the right vcpu should be preempted in order us injecting time irq into it.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 aboutAnd 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.
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
|[Prev in Thread]||Current Thread||[Next in Thread]|