[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <353732783fde46919fdcf698c326b7ed@AcuMS.aculab.com>
Date: Mon, 5 Jun 2023 10:27:46 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Thomas Gleixner' <tglx@...utronix.de>,
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: Muhammad Usama Anjum <usama.anjum@...labora.com>,
Steven Noonan <steven@...inklabs.net>,
"kernel@...labora.com" <kernel@...labora.com>
Subject: RE: Direct rdtsc call side-effect
...
> Who would have thought that rdtsc() in applications can be a problem.
> Interfaces to query time exist for a reason and it's documented by
> Microsoft:
>
> https://learn.microsoft.com/en-us/windows/win32/dxtecharts/game-timing-and-multicore-processors
>
> But sure, reading documentation is overrated...
That eve says:
"Multiprocessor and dual-core systems do not guarantee synchronization
of their cycle counters between cores."
.
> Synchronizing TSC by writing the TSC MSR is fragile as hell. This has
> been tried so often and never reliably passed all synchronization tests
> on a wide range of systems.
>
> It kinda works on single socket, but not on larger systems.
>
> We spent an insane amount of time to make timekeeping correct and I'm
> not interested at all to deal with the fallout of such a mechanim.
I've wondered whether the TSC ought to be deliberately mis-synchronised?
So the high order bits are effectively the cpu number.
It has to be said that using it as a time source was fundamentally
a bad idea.
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.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists