From: Krister Johansen <kjlx@templeofstupid.com>
To: Juergen Gross <jgross@suse.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
Marcelo Tosatti <mtosatti@redhat.com>,
Anthony Liguori <aliguori@amazon.com>,
David Reaver <me@davidreaver.com>,
Brendan Gregg <brendan@intel.com>
Subject: [PATCH linux-next] x86/xen/time: prefer tsc as clocksource when it is invariant
Date: Thu, 8 Dec 2022 08:36:50 -0800 [thread overview]
Message-ID: <20221208163650.GA3225@templeofstupid.com> (raw)
Kvm elects to use tsc instead of kvm-clock when it can detect that the
TSC is invariant.
(As of commit 7539b174aef4 ("x86: kvmguest: use TSC clocksource if
invariant TSC is exposed")).
Notable cloud vendors[1] and performance engineers[2] recommend that Xen
users preferentially select tsc over xen-clocksource due the performance
penalty incurred by the latter. These articles are persuasive and
tailored to specific use cases. In order to understand the tradeoffs
around this choice more fully, this author had to reference the
documented[3] complexities around the Xen configuration, as well as the
kernel's clocksource selection algorithm. Many users may not attempt
this to correctly configure the right clock source in their guest.
The approach taken in the kvm-clock module spares users this confusion,
where possible.
Both the Intel SDM[4] and the Xen tsc documentation explain that marking
a tsc as invariant means that it should be considered stable by the OS
and is elibile to be used as a wall clock source. The Xen documentation
further clarifies that this is only reliable on HVM and PVH because PV
cannot intercept a cpuid instruction.
In order to obtain better out-of-the-box performance, and reduce the
need for user tuning, follow kvm's approach and decrease the xen clock
rating so that tsc is preferable, if it is invariant, stable, and the
guest is a HVM or PVH domain.
[1] https://aws.amazon.com/premiumsupport/knowledge-center/manage-ec2-linux-clock-source/
[2] https://www.brendangregg.com/blog/2021-09-26/the-speed-of-time.html
[3] https://xenbits.xen.org/docs/unstable/man/xen-tscmode.7.html
[4] Intel 64 and IA-32 Architectures Sofware Developer's Manual Volume
3b: System Programming Guide, Part 2, Section 17.17.1, Invariant TSC
Signed-off-by: Krister Johansen <kjlx@templeofstupid.com>
Code-reviewed-by: David Reaver <me@davidreaver.com>
---
arch/x86/xen/time.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 9ef0a5cca96e..ca78581e4221 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -480,9 +480,22 @@ static void __init xen_time_init(void)
int cpu = smp_processor_id();
struct timespec64 tp;
- /* As Dom0 is never moved, no penalty on using TSC there */
- if (xen_initial_domain())
+ /*
+ * As Dom0 is never moved, no penalty on using TSC there.
+ *
+ * If the guest has invariant tsc, then set xen_clocksource rating
+ * below that of the tsc so that the system prefers tsc instead. This
+ * check excludes PV domains, because PV is unable to guarantee that the
+ * guest's cpuid call has been intercepted by the hypervisor.
+ */
+ if (xen_initial_domain()) {
xen_clocksource.rating = 275;
+ } else if ((xen_hvm_domain() || xen_pvh_domain()) &&
+ boot_cpu_has(X86_FEATURE_CONSTANT_TSC) &&
+ boot_cpu_has(X86_FEATURE_NONSTOP_TSC) &&
+ !check_tsc_unstable()) {
+ xen_clocksource.rating = 299;
+ }
clocksource_register_hz(&xen_clocksource, NSEC_PER_SEC);
--
2.25.1
next reply other threads:[~2022-12-08 16:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-08 16:36 Krister Johansen [this message]
2022-12-09 19:32 ` [PATCH linux-next] x86/xen/time: prefer tsc as clocksource when it is invariant Boris Ostrovsky
2022-12-12 15:57 ` Krister Johansen
2022-12-12 16:05 ` [PATCH linux-next v2] " Krister Johansen
2022-12-12 16:46 ` Jan Beulich
2022-12-12 22:05 ` Krister Johansen
2022-12-13 7:23 ` Jan Beulich
2022-12-13 18:58 ` Krister Johansen
2022-12-14 8:17 ` Jan Beulich
2022-12-14 18:01 ` Krister Johansen
2022-12-12 18:48 ` Boris Ostrovsky
2022-12-12 22:09 ` Krister Johansen
2022-12-13 21:25 ` Boris Ostrovsky
2022-12-14 18:01 ` Krister Johansen
2022-12-14 21:46 ` Boris Ostrovsky
2022-12-16 16:20 ` Krister Johansen
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=20221208163650.GA3225@templeofstupid.com \
--to=kjlx@templeofstupid.com \
--cc=aliguori@amazon.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=brendan@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=me@davidreaver.com \
--cc=mingo@redhat.com \
--cc=mtosatti@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox