Overflowing timeout

Re:Overflowing timeout by ComputerGuru on Wednesday July 14, 2021 @10:04PM (#27840736)

__rdtsc drift isn’t an AMD bug, it’s by design. The only way to use the rdtsc instruction is to pin code to the same physical core between calls. They probably just got lucky in that the drift always exceeded the time that elapsed between calls on other cpus or the Linux scheduler’s behavior on Ryzen 7 differs from other CPUs (I’m not familiar with Ryzen 7 but ThreadRipper is basically non-numa and needed patches to the scheduler under Windows to fix some pathological conditions).

[ Parent | on HN ]

Re:Overflowing timeout by wahern on Wednesday July 14, 2021 @11:33PM (#27841124)

It seems more of a QoI issue. Most Intel chips maintain synchronized (same rate of change) TSCs. That knowledge is encoded in the Linux kernel:

   /*
    * Intel systems are normally all synchronized.
    * Exceptions must mark TSC as unstable:
    */
   if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) {
    /* assume multi socket systems are not synchronized: */
    if (num_possible_cpus() > 1)
     return 1;
   }

From unsynchronized_tsc function at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[ Parent | on HN ]

Re:Overflowing timeout by antonio2368 on Thursday July 15, 2021 @02:43AM (#27842026)

> __rdtsc drift isn’t an AMD bug, it’s by design.

Yes, I should've emphasized this.

> hey probably just got lucky in that the drift always exceeded the time that elapsed between calls on other cpus

And this is also true. :D But I would say we were lucky to notice this problem at all because it really doesn't happen on that many CPUs, at least on the ones we tried out.

[ Parent | on HN ]