STRUCT BFQ_QUEUE(9)
π 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
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms