[llvm-bugs] [Bug 44773] New: steady_clock not advancing after system resumes

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Feb 4 10:10:46 PST 2020


https://bugs.llvm.org/show_bug.cgi?id=44773

            Bug ID: 44773
           Summary: steady_clock not advancing after system resumes
           Product: libc++
           Version: unspecified
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: philwill at fb.com
                CC: llvm-bugs at lists.llvm.org, mclow.lists at gmail.com

On macOS pre-Catalina we see that in some cases std::steady_clock::now() either
reverses or does not advance after the system resumes from sleep. I cannot
reproduce this effect on Catalina.

I speculate that pre-Catalina CLOCK_UPTIME_RAW was very close to the raw output
of the `RDTSC` instruction and is therefore reset to zero in some "deeper"
sleep states where the CPUs are powered-down. The circumstantial evidence for
this is that we were never able to reproduce the issue with short periods of
sleep on macs that are plugged in to an electricity supply, whereas it occurred
most often in the wild on Monday mornings when people open laptop lids after
the weekend.

I'm reporting it here because it seems to me that the current implementation of
std::steady_clock does not meet the standard's requirement that it should
"advance at a steady rate relative to real time" at least on macOS Mojave.

Workaround
==========

We have addressed this in our application by providing our own steady_clock
that's based on CLOCK_MONOTONIC_RAW.

Proposed Fix
============
I leave it to the libc++ team to decide whether to make a similar change to the
standard library - I appreciate that it's a difficult balance given the
precision concerns mentioned in https://reviews.llvm.org/D27429

Testing CLOCK_MONOTONIC_RAW on Catalina I do not encounter repeating timestamps
at nanosecond resolution so it appears that Apple have addressed that concern
mentioned in D27429.

Application-level Symptoms
==========================
In our application this manifested in a few ways. The most-obvious was very
high CPU usage after resume. When we grabbed a CPU profile it showed that we
were burning time in the spinning part of a hybrid lock - it tries to spin for
5 microseconds before suspending. Because `std::steady_clock::now()` was not
advancing it did not ever meet the condition to stop spinning.

We also saw this as bugs where scheduled work was not happening after the
desired time in our work scheduler; it would happen much later if at all.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200204/14406a3e/attachment-0001.html>


More information about the llvm-bugs mailing list