ktime_get_mono_fast_ns(9)

📦 version 7.3.1, in nixpkgs unstable

okay bestie, welcome to the ktime_get_mono_fast_ns(9) page from the Kernel API Manual 💅✨ this one is short but spicy.

🎀 NAME 🎀

ktime_get_mono_fast_ns — Fast NMI safe access to clock monotonic 💖

✨ SYNOPSIS ✨

the whole signature is literally:

u64 notrace ktime_get_mono_fast_ns (void );

🦋 ARGUMENTS 🦋

  • void — no arguments. that's it, that's the whole argument list 🫶

🌸 DESCRIPTION 🌸

🚨 real talk: this timestamp is not guaranteed to be monotonic across an update. no cap.

The timestamp is calculated by:

now = base_mono + clock_delta * slope

So if the update lowers the slope, readers who are forced to the not yet updated second array are still using the old steeper slope. it's giving “two vibes at once” 😭

       tmono ^ |    o  n |   o n |  u | o |o |12345678---> reader order

       o = old slope u = update n = new slope

in the diagram: o = old slope, u = update, n = new slope. iconic little chart tbh 🌈

So reader 6 will observe time going backwards versus reader 5. yeah. time really said “let me reverse” 💀

While other CPUs are likely to be able to observe that, the only way for a CPU local observation is when an NMI hits in the middle of the update. Timestamps taken from that NMI context might be ahead of the following timestamps. Callers need to be aware of that and deal with it. that's the assignment, bestie — handle your business 🫡

💜 SEE ALSO 💜

kernel file: ./kernel/time/timekeeping.c — and the rest of the SEE ALSO squad is:

later bestie 🫶 source/version: ./kernel/time · date: October 2026 · manual: ktime_get_mono_fast_ns(9) — mwah 💋

📦 where this page comes from