TSC: Use CPU model map to find crystal frequency#1524
Conversation
In shadow#1519 we found that the frequency from the CPU brand string can be substantially off from the TSC rate (3% in this case), so it's worth implementing more of the cpuid 0x15h method of finding the TSC rate.
Codecov Report
@@ Coverage Diff @@
## main #1524 +/- ##
==========================================
- Coverage 52.60% 52.57% -0.03%
==========================================
Files 141 141
Lines 21158 21169 +11
Branches 5345 5347 +2
==========================================
Hits 11130 11130
- Misses 7084 7096 +12
+ Partials 2944 2943 -1
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
stevenengler
left a comment
There was a problem hiding this comment.
You may have seen this already, but Linux seems to use cpuid 0x16 as well for certain processors. Maybe it would help here too: https://lore.kernel.org/patchwork/patch/1071759/
I hadn't! I was poking around some more though and found that the current methods don't look like they'll work for AMD, and haven't been able to find a method that will reliably work - https://community.amd.com/t5/server-gurus-discussions/how-can-one-find-quot-p0-frequency-quot/td-p/292863 Also came across this article, which basically recommends getting it from the kernel (via a custom module because it isn't exposed by default): https://blog.trailofbits.com/2019/10/03/tsc-frequency-for-all-better-profiling-and-benchmarking/. Given the complexity of finding the TSC rate, and that the only place we've observed to use the TSC to measure wallclock time is the vdso function (probably because of how complex it is), maybe we're better off just picking a simulated TSC rate and working on more thoroughly overriding vdso. |
In #1519 we found that the
frequency from the CPU brand string can be substantially off from the
TSC rate (3% in this case), so it's worth implementing more of the cpuid
0x15h method of finding the TSC rate.