Incorrect usage of __wt_clock to measure time

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Works as Designed
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Not Applicable
    • None
    • Storage Engines
    • None
    • None

      We use __wt_clock to measure time in milliseconds or nanoseconds all throughout WiredTiger, but that's an incorrect use of the function, which can—in some cases—return the value of RDTSC:

      /*
       * __wt_clock --
       *     Obtain a timestamp via either a CPU register or via a system call on platforms where
       *     obtaining it directly from the hardware register is not supported.
       */
      static WT_INLINE uint64_t
      __wt_clock(WT_SESSION_IMPL *session)
      {
          struct timespec tsp;
      
          /*
           * In one case we return nanoseconds, in the other we return clock ticks. That looks wrong, but
           * it's not. When simply comparing before and after values, which is returned doesn't matter.
           * When trying to calculate wall-clock time (that is, comparing a starting time with an ending
           * time), we'll subtract the two values and then call a function to convert the result of the
           * subtraction into nanoseconds. In the case where we already have nanoseconds, that function
           * has a conversion constant of 1 and we'll skip the conversion, in the case where we have clock
           * ticks, the conversion constant will be real. The reason is because doing it that way avoids a
           * floating-point operation per wall-clock time calculation.
           */
          if (__wt_process.use_epochtime) {
              __wt_epoch(session, &tsp);
              return ((uint64_t)(tsp.tv_sec * WT_BILLION + tsp.tv_nsec));
          }
          return (__wt_rdtsc());
      }
      

      We should use something like __wt_milliseconds instead. However, the use of such function is not as convenient due to a different signature, which we can change as a part of this PR.

            Assignee:
            [DO NOT USE] Backlog - Storage Engines Team
            Reporter:
            Peter Macko
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: