3 ms·

> The most noticeable last-minute change is probably that we had to revert the code that showed a good MHz value in /proc/cpuinfo even for the modern "CPU picks

> The most noticeable last-minute change is probably that we had to revert the code that showed a good MHz value in /proc/cpuinfo even for the modern "CPU picks frequency dynamically" case all sorts of applications take the tick count (rdtsc) times cpu frequency + boot time in order to get some approximation of the current time (cheaper than doing a syscall). In windows they even have an api function QueryPerformanceFrequency for getting the frequency. Now that of course is all wrong because of 'dynamic scaling of voltage and frequency' feature of the cpu. Whatever you do in software, it will be wrong in due time because of some significant changes in a lower level...

unilynx 9y ago
Then apps should not do that. It’s been possible to get the current time without using a syscall for years: http://man7.org/linux/man-pages/man7/vdso.7.html http://man7.org/linux/man-pages/man7/vdso.7.html
- MichaelMoser123 9y ago
  actually libc gettimeofday is calling __vdso_gettimeofday when available (if compiled with SHARED). http://code.metager.de/source/xref/gnu/glibc/sysdeps/unix/sysv/linux/x86/gettimeofday.c#40 http://code.metager.de/source/xref/gnu/glibc/sysdeps/unix/sy...
MichaelMoser123 9y ago
still possible to use rdtsc - you need to make sure that the thread has switched from executing on one CPU to another one, different packages have different counters. (can do it by setting thread affinity) - you need to see if CPU supports invariant TSC (cpuid reports TscInvariant = True )