* Ian Pratt [EMAIL PROTECTED] wrote:
Sigh, I don't really want to have this fight again.
i dont remember us having discussed this before, ever. If there's any
fight about monotonicity and SMP then it would be a pretty onesided
affair, with you being beaten up seriously ;-)
* Dan Hecht [EMAIL PROTECTED] wrote:
but if there's a perfect TSC available (there is such hardware) then
the TSC _is_ the best clocksource. Paravirt now turns it off
unconditionally in essence.
Not really. In the case hardware TSC is perfect, the paravirt time
counter can be
* Rusty Russell [EMAIL PROTECTED] wrote:
No. tsc is very good, it's not perfect. If a paravirt clock
registers 400 it really means pick me over the tsc.
often the TSC is not perfect, but _IF_ it's perfect, using the paravirt
driver is a pessimisation in performance.
the main problem at
On Tuesday 30 October 2007 18:37:36 Ingo Molnar wrote:
* Rusty Russell [EMAIL PROTECTED] wrote:
No. tsc is very good, it's not perfect. If a paravirt clock
registers 400 it really means pick me over the tsc.
often the TSC is not perfect, but _IF_ it's perfect, using the paravirt
driver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zachary Amsden escreveu:
On Mon, 2007-10-29 at 23:48 +0100, Ingo Molnar wrote:
* Zachary Amsden [EMAIL PROTECTED] wrote:
if it's inaccurate why are you exposing it to the guest then? Native
only uses the TSC if it's safe and accurate to do so.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ingo Molnar escreveu:
* Rusty Russell [EMAIL PROTECTED] wrote:
and just in case it's not obvious: i am not arguing for the inclusion of
the patch, i'm just pointing out the plain fact that in the case where
the TSC _is_ reliable, 5 different
On Mon, 29 Oct 2007, Glauber de Oliveira Costa wrote:
CC'ed John and removed [EMAIL PROTECTED] :)
From: Glauber de Oliveira Costa [EMAIL PROTECTED]
tsc is very good time source (when it does not have drifts, does not
change it's frequency, i.e. when it works), so it should have its rating
On Mon, 2007-10-29 at 20:10 -0300, Glauber de Oliveira Costa wrote:
From: Glauber de Oliveira Costa [EMAIL PROTECTED]
tsc is very good time source (when it does not have drifts, does not
change it's frequency, i.e. when it works), so it should have its rating
raised to a value greater than,
Ingo Molnar wrote:
* Zachary Amsden [EMAIL PROTECTED] wrote:
On Mon, 2007-10-29 at 20:10 -0300, Glauber de Oliveira Costa wrote:
From: Glauber de Oliveira Costa [EMAIL PROTECTED]
tsc is very good time source (when it does not have drifts, does not
change it's frequency, i.e. when
Zachary Amsden wrote:
On Mon, 2007-10-29 at 20:10 -0300, Glauber de Oliveira Costa wrote:
From: Glauber de Oliveira Costa [EMAIL PROTECTED]
tsc is very good time source (when it does not have drifts, does not
change it's frequency, i.e. when it works), so it should have its rating
raised
From: Glauber de Oliveira Costa [EMAIL PROTECTED]
tsc is very good time source (when it does not have drifts, does not
change it's frequency, i.e. when it works), so it should have its rating
raised to a value greater than, or equal 400.
Since it's being a tendency among paravirt clocksources to
On Tue, 2007-10-30 at 00:02 +0100, Ingo Molnar wrote:
* Zachary Amsden [EMAIL PROTECTED] wrote:
Not every guest support paravirt, but for correctness, all guests
require TSC, which must be exposed all the way up to userspace, no
matter what the efficiency or accuracy may be.
but if
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
that's totally broken then. You cannot create an SMP-safe monotonic
clocksource via interpolation - native does not do it either. Good thing
this problem got exposed, it needs to be fixed.
Sigh, I don't really
Ingo Molnar wrote:
that's totally broken then. You cannot create an SMP-safe monotonic
clocksource via interpolation - native does not do it either. Good thing
this problem got exposed, it needs to be fixed.
Sigh, I don't really want to have this fight again.
I don't really see what
* Zachary Amsden [EMAIL PROTECTED] wrote:
On Tue, 2007-10-30 at 00:02 +0100, Ingo Molnar wrote:
* Zachary Amsden [EMAIL PROTECTED] wrote:
Not every guest support paravirt, but for correctness, all guests
require TSC, which must be exposed all the way up to userspace, no
matter
On 10/29/2007 04:02 PM, Ingo Molnar wrote:
* Zachary Amsden [EMAIL PROTECTED] wrote:
On Mon, 2007-10-29 at 23:48 +0100, Ingo Molnar wrote:
* Zachary Amsden [EMAIL PROTECTED] wrote:
if it's inaccurate why are you exposing it to the guest then? Native
only uses the TSC if it's safe and
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
if it's inaccurate why are you exposing it to the guest then? Native
only uses the TSC if it's safe and accurate to do so.
It is used as part of the Xen clocksource as a short term
extrapolator, with correction parameters supplied by the
Ingo Molnar wrote:
i dont remember us having discussed this before, ever. If there's any
fight about monotonicity and SMP then it would be a pretty onesided
affair, with you being beaten up seriously ;-)
This is part of Xen's ABI, so it isn't easily changed. You're right
that getting
* Zachary Amsden [EMAIL PROTECTED] wrote:
On Mon, 2007-10-29 at 23:48 +0100, Ingo Molnar wrote:
* Zachary Amsden [EMAIL PROTECTED] wrote:
if it's inaccurate why are you exposing it to the guest then? Native
only uses the TSC if it's safe and accurate to do so.
Not every guest
Glauber de Oliveira Costa wrote:
From: Glauber de Oliveira Costa [EMAIL PROTECTED]
tsc is very good time source (when it does not have drifts, does not
change it's frequency, i.e. when it works), so it should have its rating
raised to a value greater than, or equal 400.
Since it's being a
* Zachary Amsden [EMAIL PROTECTED] wrote:
On Mon, 2007-10-29 at 20:10 -0300, Glauber de Oliveira Costa wrote:
From: Glauber de Oliveira Costa [EMAIL PROTECTED]
tsc is very good time source (when it does not have drifts, does not
change it's frequency, i.e. when it works), so it should
* Thomas Gleixner [EMAIL PROTECTED] wrote:
Since it's being a tendency among paravirt clocksources to use
values around 400, we should declare tsc as even better: So we use
500.
This patch also touches the comments on clocksource.h, which
suggests that 499 would be a limit on the
Sigh, I don't really want to have this fight again.
i dont remember us having discussed this before, ever. If there's any
fight about monotonicity and SMP then it would be a pretty onesided
affair, with you being beaten up seriously ;-)
Actually, it is possible, even for NUMA systems with
On Mon, 2007-10-29 at 23:17 +0100, Thomas Gleixner wrote:
On Mon, 29 Oct 2007, Glauber de Oliveira Costa wrote:
CC'ed John and removed [EMAIL PROTECTED] :)
From: Glauber de Oliveira Costa [EMAIL PROTECTED]
tsc is very good time source (when it does not have drifts, does not
change
On Tuesday 30 October 2007 09:17:38 Thomas Gleixner wrote:
On Mon, 29 Oct 2007, Glauber de Oliveira Costa wrote:
CC'ed John and removed [EMAIL PROTECTED] :)
From: Glauber de Oliveira Costa [EMAIL PROTECTED]
tsc is very good time source (when it does not have drifts, does not
change
Dan Hecht wrote:
Not really. In the case hardware TSC is perfect, the paravirt time
counter can be implemented directly in terms of hardware TSC; there is
no loss in optimization. This is done transparently. And virtual TSC
can be implemented this way too.
The real improvement that a
26 matches
Mail list logo