proc_timer_stats(5)

✨ proc_timer_stats(5) ✨

okay bestie, gather round, because we're reading a whole File Formats Manual page and it's giving deep lore 💅 this one's the proc_timer_stats(5) page and honestly? it's a little tragic. it's a ghost. a legend. an icon that got cancelled. let's get into it 🫶

---

💖 NAME 💖

/proc/timer_stats — timer statistics ✨ like, the receipts on who's setting timers and how much 🔥

---

🌸 DESCRIPTION 🌸

🎀 /proc/timer_stats (from Linux 2.6.21 until Linux 4.10)

so this file was a debugging facility — literally designed to make timer (ab)use across a Linux system visible to both kernel devs and user-space devs 👀 yes, "(ab)use," the manpage said it, not me 💀

devs could use it to double-check that their code does not make undue use of timers. the whole goal? avoid unnecessary wakeups and thereby optimize power consumption 🔋 protect the battery, protect the vibes, periodt.

if it's enabled in the kernel (CONFIG_TIMER_STATS) but you're not using it, it has almost zero run-time overhead and a relatively small data-structure overhead. and even if collection is enabled at run time, the overhead stays low because — and I quote the flex — all the locking is per-CPU and lookup is hashed ✨ iconic engineering behavior, no cap.

the /proc/timer_stats file multitasked like a main character: it was used both to control the sampling facility and to read out the sampled information 👑

quick heads up bestie: the timer_stats functionality is inactive on bootup 🛌 you gotta wake it up yourself.

wanna start a sampling period? say less:

# echo 1 > /proc/timer_stats

wanna stop a sampling period? okay queen, shut it down:

# echo 0 > /proc/timer_stats

and to retrieve the statistics:

$ cat /proc/timer_stats

now here's the cute part 🥰 while sampling is enabled, every single readout from /proc/timer_stats will see newly updated statistics — live updates, we love to see it. and once sampling is disabled, the sampled information is kept until a new sample period is started. that means you can read it out multiple times 🎀 no data loss, no drama.

sample output from /proc/timer_stats:

$ cat /proc/timer_stats
Timer Stats Version: v0.3
Sample period: 1.764 s
Collection: active
  255,     0 swapper/3        hrtimer_start_range_ns (tick_sched_timer)
   71,     0 swapper/1        hrtimer_start_range_ns (tick_sched_timer)
   58,     0 swapper/0        hrtimer_start_range_ns (tick_sched_timer)
    4,  1694 gnome-shell      mod_delayed_work_on (delayed_work_timer_fn)
   17,     7 rcu_sched        rcu_gp_kthread (process_timeout)
...
    1,  4911 kworker/u16:0    mod_delayed_work_on (delayed_work_timer_fn)
    1D,  2522 kworker/0:0      queue_delayed_work_on (delayed_work_timer_fn)
1029 total events, 583.333 events/sec

okay now let's decode those columns, because the output is lowkey a whole mood board 🌈

• [1] — a count of the number of events, optionally (since Linux 2.6.23) followed by the letter 'D' if this is a deferrable timer 😌
• [2] — the PID of the process that initialized the timer 🧚
• [3] — the name of the process that initialized the timer 💜
• [4] — the function where the timer was initialized; and (in parentheses) the callback function that is associated with the timer 🔥

😭 and now the sad part. during the Linux 4.11 development cycle, this file was removed because of security concerns, as it exposes information across namespaces. it's gone bestie, she's not coming back 💀

but wait — plot twist 🦋 it is possible to obtain the same information via in-kernel tracing facilities such as ftrace. so the info lives on, just in a different font. the way that we never truly lose anything ✨

---

🦋 SEE ALSO 🦋

• proc(5)

---

and that's the whole page, bestie 🥹💖 this was Linux man-pages 6.20, dated 2026-02-08, and honestly the proc_timer_stats(5) arc was short but it ATE and left no crumbs 👑 rest in power, you beautiful little debug file. slay forever 🌈✨💅