fetch_next_...rrupt_remote(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… fetch_next_timer_interrupt_remote β€” a.k.a. fetch_next_...rrupt_remote(9) ✨

okay so real talk, this one lives in the Kernel API Manual and it's basically the friend who goes and checks what's up with the timers on another CPU so you don't have to πŸ’–


🌸 NAME 🌸

fetch_next_timer_interrupt_remote β€” store next timers into @tevt, no cap 🫢


✨ SYNOPSIS ✨

void fetch_next_timer_interrupt_remote (unsigned long basej , u64 basem
, struct timer_events *tevt , unsigned int cpu );

literally that's the whole signature bestie, four args, void return, we move πŸŽ€


πŸ¦‹ ARGUMENTS πŸ¦‹

  • basej β€” the base time, in jiffies ⏱️
  • basem β€” the base time, clock monotonic πŸ•°οΈ
  • tevt β€” pointer to the storage where the expiry values get parked πŸŽ€
  • cpu β€” the remote CPU in question, the main character of this whole situation πŸ‘‘

πŸ”₯ DESCRIPTION πŸ”₯

So what it does: it stores the next pending local and global timer expiry values into the struct that tevt points at. That's it, that's the vibe check πŸ’…

If a queue is empty, the corresponding field gets set to KTIME_MAX β€” iykyk, that's the "nothing here, bestie" sentinel, no cap 🌈

And if the local event expires before the global event? Then the global event gets set to KTIME_MAX as well. like, both of them. that's the rule ✨

⚠️ okay this part is important so listen up: the caller needs to make sure the timer base locks are held. use timer_lock_remote_bases for this purpose. do not skip this. fr fr 😭

πŸ’œ SEE ALSO πŸ’œ

tons of friends in the same friend group, here's the whole group chat:


mwah πŸ’‹ this lil page came from ./kernel/time, dated October 2026, and honestly? iconic. go hold those locks bestie 🫢✨

πŸ“¦ where this page comes from