STRUCT BFQ_ENTITY(9)

✨ struct bfq_entity(9) ✨ — the Kernel API Manual page, but make it make sense

okay bestie, buckle up 💖 this one is from the Kernel API Manual (struct bfq_entity(9)) and it's literally the blueprint for the schedulable entity — the main character of BFQ's little cgroup family tree. no cap, she's iconic. 🎀

---

🌸 NAME 🌸

struct bfq_entity — schedulable entity. that's it, that's the vibe. a thing that the scheduler can actually, like, schedule. 💅

---

🦋 SYNOPSIS 🦋

struct bfq_entity {
    struct rb_node rb_node;
    bool on_st_or_in_serv;
    u64 start, finish;
    struct rb_root *tree;
    u64 min_start;
    int service;
    int budget;
    int allocated;
    int dev_weight;
    int weight;
    int new_weight;
    int orig_weight;
    struct bfq_entity *parent;
    struct bfq_sched_data *my_sched_data;
    struct bfq_sched_data *sched_data;
    int prio_changed;
  #ifdef CONFIG_BFQ_GROUP_IOSCHED;
    bool in_groups_with_pending_reqs;
  #endif;
    struct bfq_queue *last_bfqq_created;
};

look at her. so many fields. so much lore. 🫶

---

🧚 Members 🧚

ngl, the original just says "Members" and then moves on — so we're keeping it exactly that ✨ (no invented descriptions here, bestie, that would be a vibe crime 🙈)

---

👑 Description 👑

so, what is a bfq_entity, fr fr? a bfq_entity is used to represent either a bfq_queue (that's the leaf node in the cgroup hierarchy 🌱) or a bfq_group up in the upper level scheduler. every entity belongs to the sched_data of the parent group in the cgroup hierarchy. and the non-leaf entities? they also have their own sched_data, stored in my_sched_data. see, everybody gets a sched_data. slay. 💖

each entity stores its priority values independently — which would allow different weights on different devices, but highkey that functionality is not exported to userspace by now. so like, the door's there, nobody's opened it yet 🚪✨

priorities and weights get updated lazily, bestie: first you stash the new values into the new_* fields, then you set the prio_changed flag. and as soon as there's a transition in the entity state that allows the priority update to actually take place, the effective and the requested priority values are synchronized. very demure, very mindful, very deferred. 💅

unless cgroups are used, the weight value is calculated from the ioprio to export the same interface as CFQ. and when we're dealing with "well-behaved" queues — i.e., queues that do not spend too much time to consume their budget, and have true sequential behavior, and when there are no external factors breaking anticipation — the relative weights at each level of the cgroups hierarchy should be guaranteed. 🎯

⚠️ okay important safety announcement: all the fields are protected by the queue lock of the containing bfqd. no freelancing. no vibes-based locking. the bfqd queue lock or nothing, periodt. 🔒

---

🌈 SEE ALSO 🌈

go read these, they're the friend group 🫶

• Kernel file ./block/bfq-iosched.h
• struct bfq_service_tree(9)
• struct bfq_sched_data(9)
• struct bfq_weight_counter(9)
• struct bfq_ttime(9)
• struct bfq_queue(9)
• struct bfq_io_cq(9)
• struct bfq_data(9)
• struct bfq_group(9)

---

okay and that's the whole page, babe 💀✨ huge thanks to ./block for hosting this icon, and shoutout to the October 2026 release — she's fresh, she's documented, she's giving kernel internals. 🧚‍♀️💜 bye bestie, go read the source, iykyk 🎀