STRUCT BFQ_GROUP(9)

🌸 NAME 🌸

okay so bestie, this is struct bfq_group(9) from the Kernel API Manual — literally the per (device, cgroup) data structure, and it's giving main character energy, periodt 💖. No cap, this is the little per-pair home for all the BFQ group tea.

✨ SYNOPSIS ✨

Here's the whole struct, copied exactly so you can vibe-check every field 👑:

struct bfq_group {
    struct blkg_policy_data pd;
    refcount_t ref;
    struct bfq_entity entity;
    struct bfq_sched_data sched_data;
    struct bfq_data *bfqd;
    struct bfq_queue
*async_bfqq[2][IOPRIO_NR_LEVELS][BFQ_MAX_ACTUATORS];
    struct bfq_queue *async_idle_bfqq[BFQ_MAX_ACTUATORS];
    struct bfq_entity *my_entity;
    int active_entities;
    int num_queues_with_pending_reqs;
    struct rb_root rq_pos_tree;
    struct bfqg_stats stats;
 };

🫶 Members 🫶

okay so the Members section is the group chat roll call for this struct. It gives the tea on these fields — and yes, the struct above also has pd, ref, and num_queues_with_pending_reqs, with no extra blurbs in Members, so I'm not inventing lore 💅.

• entity — schedulable entity to insert into the parent group sched_data. Slay.
• sched_data — own sched_data, to contain child entities (they may be both bfq_queues and bfq_groups). Iconic.
• bfqd — the bfq_data for the device this group acts upon. That's the device bestie.
• async_bfqq — array of async queues for all the tasks belonging to the group, one queue per ioprio value per ioprio_class, except for the idle class that has only one queue. Lowkey a whole fleet.
• async_idle_bfqq — async queue for the idle class (ioprio is ignored). Periodt.
• my_entity — pointer to entity, NULL for the toplevel group; used to avoid too many special cases during group creation/migration. No cap, very practical.
• active_entities — number of active entities belonging to the group; unused for the root group. Used to know whether there are groups with more than one active bfq_entity (see the comments to the function bfq_better_to_idle). Big main-character counter energy.
• rq_pos_tree — rbtree sorted by next_request position, used when determining if two or more queues have interleaving requests (see bfq_find_close_cooperator). The way that tree keeps the receipts 💅.
• stats — stats for this bfqg. Short and iconic.

💖 Description 💖

Each (device, cgroup) pair has its own bfq_group — i.e., for each cgroup there is a set of bfq_groups, each one collecting the lower-level entities belonging to the group that are acting on the same device. It's giving one little group per device/cgroup combo, and honestly? obsessed 🦋.

Locking works as follows, bestie:

• bfqd is protected by the queue lock, RCU is used to access it from the readers.
• All the other fields are protected by the bfqd queue lock.

No cap, that's the lock lore. 🔥

🔗 SEE ALSO 🔗

Kernel file ./block/bfq-iosched.h is the one to peek at, and then these structs are the besties to check out too:

• struct bfq_service_tree(9)
• struct bfq_sched_data(9)
• struct bfq_weight_counter(9)
• struct bfq_entity(9)
• struct bfq_ttime(9)
• struct bfq_queue(9)
• struct bfq_io_cq(9)
• struct bfq_data(9)

okay bestie, that's the whole struct bfq_group(9) situation 💖✨. Cute little source/version footer shoutout: from ./block, dated October 2026 — and yes, it's still living under the struct bfq_group(9) title. Mwah 💅🫶