[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87jzwi55qo.ffs@tglx>
Date: Mon, 05 Jun 2023 16:43:59 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: David Laight <David.Laight@...LAB.COM>,
Muhammad Usama Anjum <usama.anjum@...labora.com>,
Jonathan Corbet <corbet@....net>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>,
"Guilherme G. Piccoli" <gpiccoli@...lia.com>
Cc: Steven Noonan <steven@...inklabs.net>,
"kernel@...labora.com" <kernel@...labora.com>
Subject: RE: Direct rdtsc call side-effect
On Mon, Jun 05 2023 at 10:27, David Laight wrote:
> It has to be said that using it as a time source was fundamentally
> a bad idea.
Too bad you weren't around many moons ago and educated us on that. That
would have saved us lots of trouble and work.
> Sometimes (eg micro benchmarks) you really want a TSC.
> You can extract one from the performance counters, but it is hard,
> root only, and the library functions have high and variable overhead.
Interesting view that high end databases are considered micro benchmarks
which need root access.
I'm sure you already talked to the developers of such code how they can
elimiate their performance problems when VDSO/TSC time queries are not
available.
Alternatively you have a replacement implementation to make VDSO work
with the same performance and precision based on (potentially
non-existing) legacy time sources.
There are damned good practical reasons, why we spent a lot of effort to
implement VDSO and make TSC usable at least on any modern platform.
Micro-benchmarks are definitely not one of those reasons.
Thanks,
tglx
Powered by blists - more mailing lists