STRUCT TIMER_BASE(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ struct timer_base(9) ✨

okay bestie, so this one is from the Kernel API Manual (the struct timer_base(9) page, if we're being official about it) and it's literally the per-CPU timer base πŸ’… β€” and the number of bases depends on your config, iykyk.


🌸 NAME 🌸

struct timer_base β€” per CPU timer base (and fr fr, the number of base depends on config πŸ‘‘)


πŸŽ€ SYNOPSIS πŸŽ€

struct timer_base {
    raw_spinlock_t lock;
    struct timer_list       *running_timer;
  #ifdef CONFIG_PREEMPT_RT;
    spinlock_t expiry_lock;
    atomic_t timer_waiters;
  #endif;
    unsigned long           clk;
    unsigned long           next_expiry;
    unsigned int            cpu;
    bool next_expiry_recalc;
    bool is_idle;
    bool timers_pending;
    unsigned long pending_map[BITS_TO_LONGS( WHEEL_SIZE)];
    struct hlist_head       vectors[WHEEL_SIZE];
 };

πŸ¦‹ Members πŸ¦‹

  • lock β€” the lock protecting the timer_base. literally its whole job 🫢
  • running_timer β€” so when timers are expiring, the lock gets dropped. to make sure we don't race against deleting/modifying a currently running timer, this pointer is set to the timer that's expiring at the moment. if no timer is running, the pointer is NULL. no cap πŸ’€
  • expiry_lock β€” PREEMPT_RT only: this lock is taken in softirq around timer expiry callback execution, and also when trying to delete a running timer and it wasn't successful in the first glance. it prevents priority inversion when the callback was preempted on a remote CPU and a caller tries to delete the running timer. it also prevents a life lock, when the task which tries to delete a timer preempted the softirq thread which is running the timer callback function. iconic protective behavior honestly ✨
  • timer_waiters β€” PREEMPT_RT only: tells, if there is a waiter waiting for the end of the timer callback function execution πŸ‘€
  • clk β€” clock of the timer base. it's updated before enqueue of a timer; during expiry, it is 1 offset ahead of jiffies to avoid endless requeuing to current jiffies. self-care, honestly πŸŽ€
  • next_expiry β€” expiry value of the first timer. it's updated when finding the next timer and during enqueue; the value is not valid when next_expiry_recalc is set. so like, don't trust it then πŸ™ˆ
  • cpu β€” number of CPU the timer base belongs to. its little home 🏠
  • next_expiry_recalc β€” states whether a recalculation of next_expiry is required. value is set true when a timer was deleted.
  • is_idle β€” set when timer_base is idle. it's triggered by NOHZ code. this state is only used in standard base. deferrable timers, which are enqueued remotely never wake up an idle CPU. so no matter of supporting it for this base πŸ¦‹
  • timers_pending β€” set when a timer is pending in the base. ⚠️ it is only reliable when next_expiry_recalc is not set.
  • pending_map β€” bitmap of the timer wheel; each bit reflects a bucket of the wheel. when a bit is set, at least a single timer is enqueued in the related bucket ⭐
  • vectors β€” array of lists; each array member reflects a bucket of the timer wheel. the list contains all timers which are enqueued into a specific bucket. love that for them πŸ’–

🌈 SEE ALSO 🌈

kernel file ./kernel/time/timer.c β€” plus literally the whole friend group:


πŸ’œ that's the whole page bestie, go forth and expire those timers responsibly 🫢

and for the sign-off: this cutie came out of ./kernel/time, dated October 2026. mwah πŸ’‹

πŸ“¦ where this page comes from