STRUCT BFQ_QUEUE(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… struct bfq_queue(9) β€” from the Kernel API Manual, bestie

okay so. picture this: you're deep in the block layer, and there's this one little struct that's basically the main character of BFQ scheduling. that's struct bfq_queue. let's get into it 🫢


✨ NAME ✨

struct bfq_queue β€” the leaf schedulable entity. like, the smallest thing that actually gets scheduled. that's her. πŸ‘‘


πŸ¦‹ SYNOPSIS πŸ¦‹

struct bfq_queue {
    int ref;
    int stable_ref;
    struct bfq_data *bfqd;
    unsigned short ioprio, ioprio_class;
    unsigned short new_ioprio, new_ioprio_class;
    u64 last_serv_time_ns;
    unsigned int inject_limit;
    unsigned long decrease_time_jif;
    struct bfq_queue *new_bfqq;
    struct rb_node pos_node;
    struct rb_root *pos_root;
    struct rb_root sort_list;
    struct request *next_rq;
    int queued[2];
    int meta_pending;
    struct list_head fifo;
    struct bfq_entity entity;
    struct bfq_weight_counter *weight_counter;
    int max_budget;
    unsigned long budget_timeout;
    int dispatched;
    unsigned long flags;
    struct list_head bfqq_list;
    struct bfq_ttime ttime;
    u64 io_start_time;
    u64 tot_idle_time;
    u32 seek_history;
    struct hlist_node burst_list_node;
    sector_t last_request_pos;
    unsigned int requests_within_timer;
    pid_t pid;
    struct bfq_io_cq *bic;
    unsigned long wr_cur_max_time;
    unsigned long soft_rt_next_start;
    unsigned long last_wr_start_finish;
    unsigned int wr_coeff;
    unsigned long last_idle_bklogged;
    unsigned long service_from_backlogged;
    unsigned long service_from_wr;
    unsigned long wr_start_at_switch_to_srt;
    unsigned long split_time;
    unsigned long first_IO_time;
    unsigned long creation_time;
    struct bfq_queue *waker_bfqq;
    struct bfq_queue *tentative_waker_bfqq;
    unsigned int num_waker_detections;
    u64 waker_detection_started;
    struct hlist_node woken_list_node;
    struct hlist_head woken_list;
    unsigned int actuator_idx;
};

no cap, that's the whole roster of fields β€” every single one, we don't skip πŸ’–


πŸŽ€ Members πŸŽ€

this page doesn't break the fields down one by one, bestie β€” the full rundown lives below in Description ✨


🌸 Description 🌸

okay so, what even is a bfq_queue?

it's a leaf request queue. and here's the tea: it can be associated with an io_context β€” or with more than one, if it's async or shared between cooperating processes. lowkey a social butterfly πŸ¦‹

also, it only contains I/O requests for one actuator. and yeah, that's a whole thing: an io_context is associated with a different bfq_queue for each actuator it generates I/O for. one queue per actuator, no sharing, periodt.

and the cgroup? she holds a reference to the cgroup β€” to be sure it doesn't just disappear while a bfqq still references it. why, you ask? mostly to avoid races between request issuing and task migration followed by cgroup destruction 😭 (yes that's an actual nightmare scenario, and no, we're not doing it).

last but SO not least: all the fields are protected by the queue lock of the containing bfqd. all of them. every last one. do not touch without the lock, i am literally begging πŸ™ˆ

⭐ SEE ALSO ⭐

  • Kernel file ./block/bfq-iosched.h
  • 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_io_cq(9)
  • struct bfq_data(9)
  • struct bfq_group(9)

and that's the page, bestie 🧚 this one's from the ./block source, dated October 2026, and it goes out to you as struct bfq_queue(9) β€” go forth and schedule responsibly πŸ’œβœ¨πŸŽ€

πŸ“¦ where this page comes from