STRUCT HRTIMER_CPU_BASE(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸŽ€ struct hrtimer_cpu_base(9) πŸŽ€

okay so bestie, welcome to the Kernel API Manual page for struct hrtimer_cpu_base β€” this is the per cpu clock bases, and it's honestly such a main character struct. it holds all the timer bookkeeping for one CPU, and every field is here so we're going through all of them, no skipping, periodt ✨


πŸ’– NAME πŸ’–

struct hrtimer_cpu_base β€” the per cpu clock bases 🌸


✨ SYNOPSIS ✨

struct hrtimer_cpu_base {
    raw_spinlock_t lock;
    unsigned int                    cpu;
    unsigned int                    active_bases;
    u32 clock_was_set_seq;
    bool hres_active;
    bool deferred_rearm;
    bool deferred_needs_update;
    bool hang_detected;
    bool softirq_activated;
    bool online;
  #ifdef CONFIG_HIGH_RES_TIMERS;
    unsigned int                    nr_events;
    unsigned short                  nr_retries;
    unsigned short                  nr_hangs;
    unsigned int                    max_hang_time;
  #endif;
  #ifdef CONFIG_PREEMPT_RT;
    spinlock_t softirq_expiry_lock;
    atomic_t timer_waiters;
  #endif;
    ktime_t expires_next;
    struct hrtimer                  *next_timer;
    ktime_t softirq_expires_next;
    struct hrtimer                  *softirq_next_timer;
    ktime_t deferred_expires_next;
    struct hrtimer_clock_base       clock_base[HRTIMER_MAX_CLOCK_BASES];
    call_single_data_t csd;
 };

quick vibe check on that: some of these fields only exist when CONFIG_HIGH_RES_TIMERS or CONFIG_PREEMPT_RT is on, so like… conditional queen behavior πŸ’…


🫢 Members (the good part, fr fr)

  • lock β€” the lock protecting the base and the associated clock bases and timers. it's giving bodyguard energy πŸ”₯
  • cpu β€” the cpu number. literally just which CPU this whole thing belongs to.
  • active_bases β€” a Bitfield to mark bases with active timers πŸ‘‘
  • clock_was_set_seq β€” Sequence counter of clock was set events. yes it counts them, someone has to πŸ“Š
  • hres_active β€” State of high resolution mode. the high-res situation report ✨
  • deferred_rearm β€” A deferred rearm is pending. it's on the to-do list bestie πŸ’…
  • deferred_needs_update β€” The deferred rearm must re-evaluate the first timer. like, it has to go back and re-check the first one 🫢
  • hang_detected β€” The last hrtimer interrupt detected a hang. red flag, literally 😭
  • softirq_activated β€” displays, if the softirq is raised - update of softirq related settings is not required then. so if this is up, no update needed, we can chill πŸ’€
  • online β€” CPU is online from an hrtimers point of view πŸ¦‹
  • nr_events β€” Total number of hrtimer interrupt events
  • nr_retries β€” Total number of hrtimer interrupt retries
  • nr_hangs β€” Total number of hrtimer interrupt hangs
  • max_hang_time β€” Maximum time spent in hrtimer_interrupt
  • softirq_expiry_lock β€” Lock which is taken while softirq based hrtimer are expired
  • timer_waiters β€” A hrtimer_cancel waiters for the timer callback to finish. they're waiting, be patient πŸ₯Ί
  • expires_next β€” Absolute time of the next event, is required for remote hrtimer enqueue; it is the total first expiry time (hard and soft hrtimer are taken into account). both flavors accounted for, no cap ⭐
  • next_timer β€” Pointer to the first expiring timer
  • softirq_expires_next β€” Time to check, if soft queues needs also to be expired
  • softirq_next_timer β€” Pointer to the first expiring softirq based timer
  • deferred_expires_next β€” Cached expires next value for deferred rearm πŸŽ€
  • clock_base β€” Array of clock bases for this cpu 🌈
side note: csd (a call_single_data_t) is in the struct up in the synopsis, but this page doesn't give it a member writeup β€” so i'm not out here making one up πŸ™ˆ the four nr_*/max_hang_time fields above are the CONFIG_HIGH_RES_TIMERS ones, and softirq_expiry_lock + timer_waiters are the CONFIG_PREEMPT_RT ones. iykyk πŸ’œ

πŸ“ Note πŸ“

⚠️ next_timer is just an optimization for __remove_hrtimer. Do not dereference the pointer because it is not reliable on cross cpu removals. seriously bestie, hands off the pointer on this one πŸ’€

🌈 SEE ALSO 🌈

  • Kernel file ./include/linux/hrtimer_bases.h
  • struct hrtimer_clock_base(9)

okay that's the whole page, you ate that πŸ“ this came to you from ./include/linux, dated October 2026, and it's the struct hrtimer_cpu_base(9) page β€” go forth and schedule responsibly, mwah πŸ’–πŸ§š

πŸ“¦ where this page comes from