On 01/07/2015 11:16 AM, 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.
Cc: Anthony Liguori <aligu...@amazon.com>
Signed-off-by: Imre Palik <im...@amazon.de>
---
arch/x86/xen/time.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index f473d26..c768726 100644
--- 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 */
+ if (xen_initial_domain())
+ xen_clocksource.rating = 275;
Should this only be limited to dom0? Can we do this for guests running
with TSC_MODE_NEVER_EMULATE as well?
We also have disable_migrate flag for guests (but it doesn't appear to
be accessible to a guest kernel).
-boris
+
clocksource_register_hz(&xen_clocksource, NSEC_PER_SEC);
if (HYPERVISOR_vcpu_op(VCPUOP_stop_periodic_timer, cpu, NULL) == 0) {
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
