bfq_update_next_in_service(9)

💅 bfq_update_next_in_service(9) — like, the whole manual, bestie

okay so this is a page from the Kernel API Manual, and yes it's a kernel function, and yes it's about BFQ scheduler bookkeeping, and yes we're gonna make it make sense. sit down, hydrate, let's go 🫶

---

✨ NAME ✨

bfq_update_next_in_service — the function whose whole job is to update sd->next_in_service. that's it. that's the gig. 💅

---

🌸 SYNOPSIS 🌸

bool bfq_update_next_in_service (struct bfq_sched_data *sd , struct
     bfq_entity *new_entity , bool expiration );

so it takes a struct bfq_sched_data *, a struct bfq_entity *, and a bool, and it hands you back a bool. iconic signature, no notes. ⭐

---

🎀 ARGUMENTS 🎀

• sd — the sched_data you're doing the update for. the main character of this operation tbh 👑
• new_entity — if this isn't NULL, it's a pointer to the entity whose activation, requeueing, or repositioning is the reason this function got called in the first place. like, it's the whole why of the call 🦋
• expiration — id true, this function is being invoked after the expiration of the in-service entity. yes bestie, that's what the page says, i'm not fixing it, i'm just delivering it 🙈

---

💖 DESCRIPTION 💖

so this function is called to update sd->next_in_service, and here's the thing — that field can change as a consequence of the insertion or extraction of an entity into/from one of the active trees of sd. highkey the plot of the whole function. 🔥

and those insertions/extractions happen as a consequence of activations/deactivations of entities. some activations are implementing the second, requeueing phase of the mechanism used to reposition an entity in its active tree — and for the details on that, the page literally says: see comments on __bfq_activate_entity and __bfq_requeue_entity. so go read those comments, bestie, they're the lore 📖

in both of the last two activation sub-cases, new_entity points to the just activated or requeued entity. no cap.

it returns true if sd->next_in_service changes in such a way that entity->parent may become the next_in_service for its parent entity. yes, entity->parent — the page says entity, and we do not improvise around here 💀

---

🌈 SEE ALSO 🌈

kernel file ./block/bfq-wf2q.c, plus the whole friend group 💜:

bfq_gt(9), bfq_delta(9), bfq_calc_finish(9), bfq_entity_of(9), bfq_extract(9), bfq_idle_extract(9), bfq_insert(9), bfq_update_min(9), bfq_update_active_node(9), bfq_update_active_tree(9), bfq_active_insert(9), bfq_ioprio_to_weight(9), bfq_weight_to_ioprio(9), bfq_find_deepest(9), bfq_active_extract(9), bfq_idle_insert(9), bfq_forget_entity(9), bfq_put_idle_entity(9), bfq_forget_idle(9), bfq_bfqq_served(9), bfq_bfqq_charge_time(9), __bfq_activate_entity(9), __bfq_requeue_entity(9), bfq_activate_requeue_entity(9), __bfq_deactivate_entity(9), bfq_deactivate_entity(9), bfq_calc_vtime_jump(9), bfq_first_active_entity(9), __bfq_lookup_next_entity(9), bfq_lookup_next_entity(9)

---

⚠️ quick vibe check: sd->next_in_service is genuinely the thing getting mutated here, so pls read the __bfq_activate_entity and __bfq_requeue_entity comments before you go poking at it. trust. 🧚

---

and that's the page!! 🍓 this lil gem lives in ./block, dated October 2026, and that's the whole sign-off bestie — mwah, go read your kernel source 💖✨