On 01/13/2015 11:17 AM, Boris Ostrovsky wrote:
On 01/13/2015 11:07 AM, David Vrabel wrote:
On 13/01/15 15:42, Boris Ostrovsky wrote:
On 01/13/2015 04:52 AM, David Vrabel wrote:
On 13/01/15 08:14, Imre Palik wrote:
From: "Palik, Imre" <im...@amazon.de>
In Dom0's the use of the TSC clocksource (whenever it is stable
enough to
be used) instead of the Xen clocksource should not cause any
issues, as
Dom0 VMs never live-migrated. The TSC clocksource is somewhat more
efficient than the Xen paravirtualised clocksource, thus it should
have
higher rating.
This patch decreases the rating of the Xen clocksource in Dom0s to
275.
Which is half-way between the rating of the TSC clocksource (300) and
the
hpet clocksource (250).
I'm happy with this but would like to see acks from those who objected
to v1.
David
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -487,6 +487,10 @@ static void __init xen_time_init(void)
int cpu = smp_processor_id();
struct timespec tp;
+ /* As Dom0 is never moved, no penalty on using TSC there */
Again, why not any PV guest with TSC_MODE_NEVER_EMULATE?
Surely if TSC_MODE_NEVER_EMULATE is set then the TSC is /not/ stable
across a guest save/restore thus the PV clocksource must be used?
TSC is declared stable when !d->disable_migrate && !d->arch.vtsc, with
vtsc being 0 with TSC_MODE_NEVER_EMULATE (per domain_cpuid()).
I think I inverted domain_cpuid's logic here but my point was that we
use'd use combination of TSC_MODE_NEVER_EMULATE and CPUID flag
indicating TSC stability to pick the clocksource.
-boris
And if TSC is not stable as seen by CPUID (which would be the case if
disable_migrate is not set) then kernel won't use TSC as clocksource
anyway, regardless of rating value, won't it?
-boris
I don't think we want to assume that TSC_MODE_NEVER_EMULATE => never
migrate.
David
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
