From: Dor Laor <dlaor@redhat.com>
To: qemu-devel@nongnu.org
Cc: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [RESEND][PATCH 0/3] Fix guest time drift under heavy load.
Date: Wed, 12 Nov 2008 14:38:57 +0200 [thread overview]
Message-ID: <491ACE61.6000009@redhat.com> (raw)
In-Reply-To: <5d6222a80811120354i5deff074g8892be066b88c8cc@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2243 bytes --]
Glauber Costa wrote:
> On Wed, Nov 12, 2008 at 9:42 AM, Gleb Natapov <gleb@redhat.com> 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.
[-- Attachment #2: Type: text/html, Size: 3041 bytes --]
next prev parent reply other threads:[~2008-11-12 12:42 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-29 15:22 [Qemu-devel] [RESEND][PATCH 0/3] Fix guest time drift under heavy load Gleb Natapov
2008-10-29 15:22 ` [Qemu-devel] [PATCH 1/3] Change qemu_set_irq() to return status information Gleb Natapov
2008-10-29 15:22 ` [Qemu-devel] [PATCH 2/3] Fix time drift problem under high load when PIT is in use Gleb Natapov
2008-10-29 15:22 ` [Qemu-devel] [PATCH 3/3] Fix time drift problem under high load when RTC " Gleb Natapov
2008-11-05 12:46 ` Dor Laor
2008-10-31 19:17 ` [Qemu-devel] [RESEND][PATCH 0/3] Fix guest time drift under heavy load Anthony Liguori
2008-11-02 13:04 ` Gleb Natapov
2008-11-05 12:45 ` Dor Laor
2008-11-05 15:48 ` andrzej zaborowski
2008-11-05 16:33 ` Anthony Liguori
2008-11-06 7:16 ` Gleb Natapov
2008-11-06 9:37 ` andrzej zaborowski
2008-11-06 10:08 ` Gleb Natapov
2008-11-06 13:21 ` andrzej zaborowski
2008-11-06 14:18 ` Gleb Natapov
2008-11-06 14:35 ` andrzej zaborowski
2008-11-06 15:04 ` Gleb Natapov
2008-11-06 15:41 ` Anthony Liguori
2008-11-07 23:18 ` andrzej zaborowski
2008-11-08 8:23 ` Gleb Natapov
2008-11-06 13:44 ` Paul Brook
2008-11-05 17:43 ` Gleb Natapov
2008-11-06 17:28 ` David S. Ahern
2008-11-05 16:43 ` Anthony Liguori
2008-11-06 3:55 ` Jamie Lokier
2008-11-06 8:12 ` Gleb Natapov
2008-11-06 14:10 ` Anthony Liguori
2008-11-06 14:24 ` Paul Brook
2008-11-06 14:40 ` Anthony Liguori
2008-11-06 14:51 ` Gleb Natapov
2008-11-06 15:37 ` Anthony Liguori
2008-11-08 8:36 ` Gleb Natapov
2008-11-08 22:14 ` Dor Laor
2008-11-09 7:40 ` Gleb Natapov
2008-11-09 16:38 ` Anthony Liguori
2008-11-09 21:00 ` Avi Kivity
2008-11-09 16:36 ` Anthony Liguori
2008-11-10 14:37 ` Gleb Natapov
2008-11-10 15:24 ` Anthony Liguori
2008-11-10 15:29 ` Gleb Natapov
2008-11-10 15:46 ` Anthony Liguori
2008-11-10 15:51 ` Gleb Natapov
2008-11-11 14:43 ` Gleb Natapov
2008-11-11 17:26 ` Anthony Liguori
2008-11-11 20:17 ` Anthony Liguori
2008-11-12 11:42 ` Gleb Natapov
2008-11-12 11:54 ` Glauber Costa
2008-11-12 12:38 ` Dor Laor [this message]
2008-11-06 3:41 ` Jamie Lokier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=491ACE61.6000009@redhat.com \
--to=dlaor@redhat.com \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).