qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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).