All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <ian.jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xen.org
Cc: Olaf Hering <olaf@aepfle.de>
Subject: [PATCH] xen: preserve native TSC speed during migration between identical hosts
Date: Wed, 24 May 2017 16:25:05 +0200	[thread overview]
Message-ID: <20170524142505.11460-1-olaf@aepfle.de> (raw)

After migrating a domU to another identical host a performance drop can
be observed. One reason is that before migration TSC was accessed at
native speed, after migration TSC has to be emulated. This happens
because the measured CPU frequency is not accurate, the values differ
even between reboots.

To avoid the emulation a tolerance range can be specified during boot
with "vtsc-tolerance=N".  If the frequency expected by the domU is
within the range, TSC access from the domU will remain native. If the
domU is migrated to another machine type TSC might be emulated.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
 docs/man/xen-tscmode.pod.7          | 11 +++++++----
 docs/misc/xen-command-line.markdown | 10 ++++++++++
 xen/arch/x86/time.c                 | 14 +++++++++++++-
 3 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/docs/man/xen-tscmode.pod.7 b/docs/man/xen-tscmode.pod.7
index 3bbc96f201..e04af70855 100644
--- a/docs/man/xen-tscmode.pod.7
+++ b/docs/man/xen-tscmode.pod.7
@@ -206,10 +206,13 @@ TSC-safe, rdtsc will execute at hardware speed; if it is not, rdtsc
 will be emulated.  Once a virtual machine is save/restored or migrated,
 however, there are two possibilities: TSC remains native IF the source
 physical machine and target physical machine have the same TSC frequency
-(or, for HVM/PVH guests, if TSC scaling support is available); else TSC
-is emulated.  Note that, though emulated, the "apparent" TSC frequency
-will be the TSC frequency of the initial physical machine, even after
-migration.
+(or, for HVM/PVH guests, if TSC scaling support is available); else TSC is
+emulated. The Xen cmdline option "vtsc-tolerance" allows host admins to
+specify a tolerance range in case the measured frequency of supposedly
+identical machines differs slightly. If the frequency on the target machine
+is within the range the tsc_mode remains native.
+Note that, though emulated, the "apparent" TSC frequency will be the TSC
+frequency of the initial physical machine, even after migration.
 
 For environments where both TSC-safeness AND highest performance
 even across migration is a requirement, application code can be specially
diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 44d99852aa..ff92975a15 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1723,6 +1723,16 @@ Note that if **watchdog** option is also specified vpmu will be turned off.
 As the virtualisation is not 100% safe, don't use the vpmu flag on
 production systems (see http://xenbits.xen.org/xsa/advisory-163.html)!
 
+### vtsc-tolerance
+> `= <integer>`
+
+> Default: `0`
+
+Specify the tolerated difference of pCPUs clock frequency in kHz.
+This option affects only domUs which have tsc\_mode=default enabled.
+If the frequency expected by a domU is within the tolerance range tsc
+will remain native. Otherwise tsc emulation will be used for the domU.
+
 ### vwfi
 > `= trap | native
 
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 655af33cb3..b290e8aca9 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -41,6 +41,9 @@
 static char __initdata opt_clocksource[10];
 string_param("clocksource", opt_clocksource);
 
+static unsigned int __read_mostly opt_vtsc_tolerance;
+integer_param("vtsc-tolerance", opt_vtsc_tolerance);
+
 unsigned long __read_mostly cpu_khz;  /* CPU clock frequency in kHz. */
 DEFINE_SPINLOCK(rtc_lock);
 unsigned long pit0_ticks;
@@ -2009,6 +2012,8 @@ void tsc_set_info(struct domain *d,
                   uint32_t tsc_mode, uint64_t elapsed_nsec,
                   uint32_t gtsc_khz, uint32_t incarnation)
 {
+    uint32_t khz_diff, tolerated;
+
     if ( is_idle_domain(d) || is_hardware_domain(d) )
     {
         d->arch.vtsc = 0;
@@ -2024,6 +2029,13 @@ void tsc_set_info(struct domain *d,
         d->arch.vtsc_offset = get_s_time() - elapsed_nsec;
         d->arch.tsc_khz = gtsc_khz ?: cpu_khz;
         set_time_scale(&d->arch.vtsc_to_ns, d->arch.tsc_khz * 1000);
+        if (!opt_vtsc_tolerance) {
+            tolerated = d->arch.tsc_khz == cpu_khz;
+        } else {
+            khz_diff = cpu_khz > d->arch.tsc_khz ?
+                       cpu_khz - d->arch.tsc_khz : d->arch.tsc_khz - cpu_khz;
+            tolerated = khz_diff <= opt_vtsc_tolerance;
+        }
 
         /*
          * In default mode use native TSC if the host has safe TSC and
@@ -2033,7 +2045,7 @@ void tsc_set_info(struct domain *d,
          * d->arch.tsc_khz == cpu_khz. Thus no need to check incarnation.
          */
         if ( tsc_mode == TSC_MODE_DEFAULT && host_tsc_is_safe() &&
-             (d->arch.tsc_khz == cpu_khz ||
+             (tolerated ||
               (is_hvm_domain(d) &&
                hvm_get_tsc_scaling_ratio(d->arch.tsc_khz))) )
         {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

             reply	other threads:[~2017-05-24 14:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-24 14:25 Olaf Hering [this message]
2017-05-24 15:09 ` [PATCH] xen: preserve native TSC speed during migration between identical hosts Konrad Rzeszutek Wilk
2017-05-24 15:25   ` Olaf Hering
2017-05-24 15:33     ` Konrad Rzeszutek Wilk
2017-05-24 15:44       ` Olaf Hering
2017-05-29 14:45       ` Jan Beulich
2017-05-30  6:36         ` Olaf Hering
2017-05-30  7:25           ` Jan Beulich
2017-05-30  9:27       ` Olaf Hering
2017-05-30 14:28         ` Konrad Rzeszutek Wilk
2017-05-29 14:50 ` Jan Beulich
2017-05-30  6:41   ` Olaf Hering
2017-05-30  7:27     ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170524142505.11460-1-olaf@aepfle.de \
    --to=olaf@aepfle.de \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.