All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Dor Laor <dor.laor@qumranet.com>
Cc: kvm@vger.kernel.org, Avi Kivity <avi@qumranet.com>,
	Gleb Natapov <gleb@qumranet.com>
Subject: Re: [PATCH 2/2] Remove -tdf
Date: Tue, 22 Jul 2008 20:20:41 -0500	[thread overview]
Message-ID: <48868769.7050307@codemonkey.ws> (raw)
In-Reply-To: <48865934.8070007@qumranet.com>

Dor Laor wrote:
> Anthony Liguori wrote:
>> The last time I posted the KVM patch series to qemu-devel, the -tdf 
>> patch met with
>> some opposition.  Since today we implement timer catch-up in the 
>> in-kernel PIT and
>> the in-kernel PIT is used by default, it doesn't seem all that 
>> valuable to have
>> timer catch-up in userspace too.
>>
>> Removing it will reduce our divergence from QEMU.
>>
>>   
> IMHO the in kernel PIT should go away, there is no reason to keep it 
> except that userspace PIT drifts.

I agree fully :-)  But there's certainly no reason to keep -tdf and the 
in-kernel PIT.  Since we're using the in-kernel PIT right now, I'd like 
to get rid of -tdf.

> Currently both in-kernel PIT and even the in kernel irqchips are not 
> 100% bullet proof.
> Of course this code is a hack, Gleb Natapov has send better fix for 
> PIT/RTC to qemu list.
> Can you look into them:
> http://www.mail-archive.com/kvm@vger.kernel.org/msg01181.html

Paul Brook's initial feedback is still valid.  It causes quite a lot of 
churn and may not jive well with a virtual time base.  An advantage to 
the current -tdf patch is that it's more contained.  I don't think 
either approach is going to get past Paul in it's current form.

I'd still like to see some harder evidence of the benefits of tdf.  For 
a specific guest, with a specific configuration, how much better is the 
drift with this series.  The answer shouldn't be "movie's play better" :-)

Also, it's important that this is reproducible in upstream QEMU and not 
just in KVM.  If we can make a compelling case for the importance of 
this, we can possibly work out a compromise.

Regards,

Anthony Liguori


  reply	other threads:[~2008-07-23  1:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-22 19:50 [PATCH 1/2] Fix bad merge Anthony Liguori
2008-07-22 19:50 ` [PATCH 2/2] Remove -tdf Anthony Liguori
2008-07-22 22:03   ` Dor Laor
2008-07-23  1:20     ` Anthony Liguori [this message]
2008-07-23  2:46       ` David S. Ahern
2008-07-23  5:58       ` Gleb Natapov
2008-07-23 15:31         ` Anthony Liguori
2008-07-24 22:55           ` Dor Laor
2008-07-27  9:38           ` Avi Kivity
2008-07-27  8:05   ` Avi Kivity
2008-07-27  8:02 ` [PATCH 1/2] Fix bad merge Avi Kivity

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=48868769.7050307@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=avi@qumranet.com \
    --cc=dor.laor@qumranet.com \
    --cc=gleb@qumranet.com \
    --cc=kvm@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.