[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200710302152.27077.rusty@rustcorp.com.au>
Date: Tue, 30 Oct 2007 21:52:26 +1100
From: Rusty Russell <rusty@...tcorp.com.au>
To: Ingo Molnar <mingo@...e.hu>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Glauber de Oliveira Costa <gcosta@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
Jeremy Fitzhardinge <jeremy@...p.org>, avi@...amnet.com,
kvm-devel@...ts.sourceforge.net, John Stultz <johnstul@...ibm.com>
Subject: Re: [PATCH] raise tsc clocksource rating
On Tuesday 30 October 2007 18:37:36 Ingo Molnar wrote:
> * Rusty Russell <rusty@...tcorp.com.au> 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 the moment is that there's no mechanism at the
> moment to convey to the guest the information that the TSC is "perfect",
> and to convey the calibration values.
The host can communicate to the guest what clock to use: the guest can decide
to register a paravirt clock or not depending on whether it wants to leave it
to the TSC.
For a while we couldn't remove the TSC cpuid capability in the guest, because
if you configured your kernel in some ways it was hardcoded on. I think
the "all 686+ have a tsc" assumption has now been fixed, so I should change
the lguest clock to do as you said: register its clock at lower prio to the
TSC and then the host can simply remove the TSC cpuid if it isn't suitable
for the guest to use.
ISTR the core TSC timing code (which lguest could use) and various hardware
manipulations (which lguest couldn't) were intertwined, but I'll have to go
back and check exactly what the issue was.
> and just in case it's not obvious: i am not arguing for the inclusion of
> the patch
Unfortunately, you and Thomas both acked the patch. This says v bad things
about how much review kernel patches get.
Cheers,
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists