throtl_sche...ext_dispatch(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ NAME ✨

okay bestie, welcome to the Kernel API Manual page for throtl_schedule_next_dispatch β€” schedule the next dispatch cycle, periodt πŸ’…


🌸 SYNOPSIS 🌸

bool throtl_schedule_next_dispatch (struct throtl_service_queue *sq ,
bool force );

πŸŽ€ ARGUMENTS πŸŽ€

  • sq β€” the service_queue we’re scheduling dispatch for, bestie ✨
  • force β€” force scheduling, no cap πŸ’…

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so the whole move here is to arm sq->pending_timer so that the next dispatch cycle starts on the dispatch time of the first pending child. The return vibe is true if either timer is armed or there’s no pending child left. It’s false if the current dispatch window is still open and the caller should continue dispatching. iykyk 🫢

If force is true, the dispatch timer is always scheduled and this function is guaranteed to return true. This is the one for when the caller can’t dispatch itself and needs to invoke pending_timer unconditionally. πŸ’–

🚨 note note note: forced scheduling is likely to induce a short delay before dispatch starts even if sq->first_pending_disptime is not in the future, and thus it shouldn’t be used in hot paths. periodt πŸ’€

🌈 SEE ALSO 🌈

Kernel file ./block/blk-throttle.c plus the whole friend group:


source/version + date tea: ./block, October 2026, and the page label is throtl_sche...ext_dispatch(9) β€” bye bestie, mwah πŸ’…πŸ’–

πŸ“¦ where this page comes from