Re: [PATCH] raise tsc clocksource rating

[Rusty Russell <rusty@rustcorp.com.au>]

On Tuesday 30 October 2007 18:37:36 Ingo Molnar wrote:
> * Rusty Russell <rusty@rustcorp.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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/