about summary refs log tree commit diff
path: root/library/std/src
diff options
context:
space:
mode:
authorAli Saidi <alisaidi@amazon.com>2021-09-04 15:25:55 -0500
committerAli Saidi <alisaidi@amazon.com>2021-09-04 15:28:16 -0500
commita333b91e5b252eba2d3dee10454c386582bf75ba (patch)
treebe76263e3bd396f83f04e719de28849a026771aa /library/std/src
parent72a51c39c69256c8a8256e775f2764a1983048d4 (diff)
downloadrust-a333b91e5b252eba2d3dee10454c386582bf75ba.tar.gz
rust-a333b91e5b252eba2d3dee10454c386582bf75ba.zip
linux/aarch64 Now() should be actually_monotonic()
While issues have been seen on arm64 platforms the Arm architecture requires
that the counter monotonically increases and that it must provide a uniform
view of system time (e.g. it must not be possible for a core to receive a
message from another core with a time stamp and observe time going backwards
(ARM DDI 0487G.b D11.1.2). While there have been a few 64bit SoCs that have
bugs (#49281, #56940) which cause time to not monotonically increase, these have
been fixed in the Linux kernel and we shouldn't penalize all Arm SoCs for those
who refuse to update their kernels:
SUN50I_ERRATUM_UNKNOWN1 - Allwinner A64 / Pine A64 - fixed in 5.1
FSL_ERRATUM_A008585 - Freescale LS2080A/LS1043A - fixed in 4.10
HISILICON_ERRATUM_161010101 - Hisilicon 1610 - fixed in 4.11
ARM64_ERRATUM_858921 - Cortex A73 - fixed in 4.12

255a3f3e183 std: Force `Instant::now()` to be monotonic added a mutex to work around
this problem and a small test program using glommio shows the majority of time spent
acquiring and releasing this Mutex. 3914a7b0da8 tries to improve this, but actually
makes it worse on big systems as for 128b atomics a ldxp/stxp pair (and
successful loop) is required which is expensive as a lock and because of how
the load/store-exclusives scale on large Arm systems is both unfair to threads
and tends to go backwards in performance.
Diffstat (limited to 'library/std/src')
-rw-r--r--library/std/src/sys/unix/time.rs1
-rw-r--r--library/std/src/time.rs14
2 files changed, 15 insertions, 0 deletions
diff --git a/library/std/src/sys/unix/time.rs b/library/std/src/sys/unix/time.rs
index 7dc09add27f..824283ef6c4 100644
--- a/library/std/src/sys/unix/time.rs
+++ b/library/std/src/sys/unix/time.rs
@@ -303,6 +303,7 @@ mod inner {
         pub fn actually_monotonic() -> bool {
             (cfg!(target_os = "linux") && cfg!(target_arch = "x86_64"))
                 || (cfg!(target_os = "linux") && cfg!(target_arch = "x86"))
+                || (cfg!(target_os = "linux") && cfg!(target_arch = "aarch64"))
                 || cfg!(target_os = "fuchsia")
         }
 
diff --git a/library/std/src/time.rs b/library/std/src/time.rs
index e9207ee3617..5e2ce6d3f46 100644
--- a/library/std/src/time.rs
+++ b/library/std/src/time.rs
@@ -263,6 +263,20 @@ impl Instant {
         //
         // To hopefully mitigate the impact of this, a few platforms are
         // excluded as "these at least haven't gone backwards yet".
+        //
+        // While issues have been seen on arm64 platforms the Arm architecture
+        // requires that the counter monotonically increases and that it must
+        // provide a uniform view of system time (e.g. it must not be possible
+        // for a core to recieve a message from another core with a time stamp
+        // and observe time going backwards (ARM DDI 0487G.b D11.1.2). While
+        // there have been a few 64bit SoCs that have bugs which cause time to
+        // not monoticially increase, these have been fixed in the Linux kernel
+        // and we shouldn't penalize all Arm SoCs for those who refuse to
+        // update their kernels:
+        // SUN50I_ERRATUM_UNKNOWN1 - Allwinner A64 / Pine A64 - fixed in 5.1
+        // FSL_ERRATUM_A008585 - Freescale LS2080A/LS1043A - fixed in 4.10
+        // HISILICON_ERRATUM_161010101 - Hisilicon 1610 - fixed in 4.11
+        // ARM64_ERRATUM_858921 - Cortex A73 - fixed in 4.12
         if time::Instant::actually_monotonic() {
             return Instant(os_now);
         }