hesela.devLinux I/O priority
Linux I/O priority assigns a scheduling class and level to a thread's I/O, with effects determined by the storage path and scheduler.
Scope: ioprio_set selects threads, a process group or a user. IOPRIO_WHO_PROCESS with who=0 addresses the calling thread, not automatically every sibling thread; CLONE_IO can share an I/O context. [1]
Classes: realtime (RT), best-effort (BE) and idle (IDLE) express scheduling priority. BE levels run from 0 (highest) to 7 (lowest), but their effect is scheduler-specific. Linux 6.12 documentation names BFQ and mq-deadline as supporting priorities. [2]
Interpretation: BFQ maps levels to baseline weights; low-latency heuristics can raise effective weights. Linux v6.12 mq-deadline selects class queues and allows aged lower-priority requests to proceed; its dispatch does not use the within-class level. The realtime name alone supplies no request-completion deadline. [3] [4]
Writeback: ordinary buffered asynchronous writes are later issued outside the dirtying thread's context. Do not infer their priority from that thread's setting. Cgroup io.prio.class can also change request classes; io.max separately limits per-device BPS or IOPS and permits temporary bursts. [1] [5]
Relations
- related
- I/O scheduler, Budget Fair Queueing (BFQ), mq-deadline, cgroup v2 I/O controller, Semi-preemptible I/O
Limitations
- Changing host scheduling priority does not reserve private SSD channels or make an in-flight device command preemptible. [7]
- BFQ strict_guarantees waits for outstanding I/O to complete before dispatching another request, trading device parallelism for service-order control; low_latency weight raising is a separate policy. [3]
Citations
- Linux man-pages: ioprio_set(2), thread scope and asynchronous writes
- Linux v6.12: block I/O priorities and scheduler support
- Linux 6.12: BFQ per-process ioprio, weights and idle-class service
- Linux v6.12: mq-deadline class queues and priority aging
- Linux 6.12: cgroup v2 I/O limits, writeback and priority policy
- Valente and Andreolini, SYSTOR 2012: Improving Application Responsiveness with the BFQ Disk I/O Scheduler
- Hesela: Sharing an SSD: who pays for the slowdown?
Sources & caveats
- Kernel behavior is scoped to Linux v6.12 documentation and source; no device benchmark or latency guarantee is inferred.
- The man-page API and writeback scope are used here, not its historical CFQ-only scheduler-support paragraph.
- The SYSTOR 2012 BFQ study explains responsiveness-oriented weight raising on three rotational-disk systems; it is historical evidence, not an NVMe benchmark. [6]