lkml.org 
[lkml]   [2023]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: Direct rdtsc call side-effect
Date
...
> 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)

\
 
 \ /
  Last update: 2023-06-05 12:29    [W:0.125 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site