scx_bpf_now(9)

📦 version 7.3.1, in nixpkgs unstable

💅 scx_bpf_now — Kernel API Manual, but make it make sense 🫶

okay bestie, so this page is scx_bpf_now(9) from the Kernel API Manual and it's literally about getting a clock. sounds boring? no. because this clock is fast. let's get into it ✨

🌸 NAME 🌸

scx_bpf_now — returns a high-performance, monotonically non-decreasing clock for the current CPU. and like, the clock it hands you back is in nanoseconds. that's it. that's the vibe 💅

🎀 SYNOPSIS 🎀

__bpf_kfunc u64 scx_bpf_now (void );

literally just call it. no cap.

🦋 ARGUMENTS 🦋

  • void — no arguments. none. zero. it takes nothing, it gives you nanoseconds. icon behaviour, honestly 👑

✨ DESCRIPTION ✨

okay so here's the tea — it provides these properties, and yes we're doing all three, numbered, in order:

  1. High performance — so many BPF schedulers call bpf_ktime_get_ns constantly to account for execution time and track tasks' runtime properties. obsessed with the diligence, but here's the problem 😭: on some hardware platforms, bpf_ktime_get_ns — which eventually reads a hardware timestamp counter — is neither performant nor scalable. so scx_bpf_now aims to provide a high-performance clock by using the rq clock in the scheduler core whenever possible. yes ma'am 🫶
  2. High enough resolution for the BPF scheduler use cases — in most BPF scheduler use cases, the required clock resolution is lower than the most accurate hardware clock (e.g., rdtsc in x86). scx_bpf_now basically uses the rq clock in the scheduler core whenever it is valid. and what counts as valid? it considers that the rq clock is valid from the time the rq clock is updated (update_rq_clock) until the rq is unlocked (rq_unpin_lock). write that down 📝
  3. Monotonically non-decreasing clock for the same CPU — scx_bpf_now guarantees the clock never goes backward when comparing them in the same CPU. but bestie, hear me: when comparing clocks in different CPUs, there is no such guarantee — the clock can go backward. it provides a monotonically non-decreasing clock so that it would provide the same clock values in two different scx_bpf_now calls in the same CPU during the same period of when the rq clock is valid. say it with me: same CPU, safe 💖 different CPU, watch out 💀
⚠️ not me warning you twice: cross-CPU comparisons can go backward. that's not a bug, that's just the deal. 🙈

🌈 SEE ALSO 🌈

before you go, the whole extended friend group. the Kernel file ./kernel/sched/ext/ext.c and, like, everyone:

💜 ok that's the whole page, bye 💜

this iconic little number came out of ./kernel/sched/ext and it's dated October 2026. go call scx_bpf_now responsibly, and remember: same CPU = monotonic, different CPU = chaos 🌈✨🍓

📦 where this page comes from