Skip to content

disable I/O priority when prio_aging_expire is zero - #1158

Open
blktests-ci[bot] wants to merge 2 commits into
linus-master_basefrom
series/1148773=>linus-master
Open

disable I/O priority when prio_aging_expire is zero#1158
blktests-ci[bot] wants to merge 2 commits into
linus-master_basefrom
series/1148773=>linus-master

Conversation

@blktests-ci

@blktests-ci blktests-ci Bot commented Aug 20, 2026

Copy link
Copy Markdown

Pull request for series with
subject: disable I/O priority when prio_aging_expire is zero
version: 1
url: https://patchwork.kernel.org/project/linux-block/list/?series=1148773

Ye Bin added 2 commits August 20, 2026 03:00
Since the mq-deadline scheduler introduced support for I/O priorities,
if a process does not have an I/O priority configured, it becomes bound
to the process's scheduling priority. This change forces applications to
re-plan their I/O priorities. However, applications do not care about I/O
priorities, yet now they cannot disable priorities.

Setting prio_aging_expire to zero does not actually turn off I/O
priority in mq-deadline. Instead the priority aging path in
dd_dispatch_prio_aged_requests() is invoked with "now - 0 == now",
which causes best-effort and idle requests to be dispatched ahead of
pending real-time requests through the aging path -- a classic
priority inversion, not the "priority disabled" behavior users expect
when writing zero.

Treat a zero prio_aging_expire as an explicit request to disable I/O
priority:

  * dd_insert_request() and dd_request_merge() file every request in
    the DD_BE_PRIO bucket, so the scheduler no longer distinguishes
    between RT, BE and IDLE classes.

  * dd_dispatch_prio_aged_requests() short-circuits when
    prio_aging_expire is zero, closing the aging path that caused the
    inversion.

  * dd_request_merged() and dd_merged_requests() now look up the
    per-priority bucket from rq->elv.priv[0] instead of recomputing it
    from the request ioprio.  Once priority is disabled the request
    ioprio no longer reflects the bucket the request lives in, so the
    old computation would touch the wrong rb-tree and FIFO list.

Switching the mode while I/O is in flight could itself invert
priorities, because requests already queued in the RT or IDLE buckets
would keep being dispatched by priority until they drain.  Follow the
same sequence used by elevator_switch(): when the sysfs store observes
a transition from a non-zero value to zero it freezes the queue (which
blocks new upper-layer I/O in blk_queue_enter() and waits for every
outstanding request to complete, draining the scheduler), quiesces the
queue so that no dispatch is in progress, flips prio_aging_expire to
zero, then unquiesces and unfreezes.  New I/O arriving after the
switch lands in the best-effort bucket.  Writing a non-zero value
re-enables priority without draining.

Signed-off-by: Ye Bin <yebin10@huawei.com>
Allow the default value of prio_aging_expire to be overridden at load
time, in milliseconds to match the sysfs attribute:

  - built-in:  mq_deadline.prio_aging_expire=0 on the kernel command line
  - module:    modprobe mq_deadline prio_aging_expire=0

A value of zero disables I/O priority from boot/load: every request is
filed in the best-effort bucket and the priority aging path is
bypassed, so systems that do not want RT/BE/IDLE distinction can opt
out without writing to sysfs after every queue creation.

Previously prio_aging_expire was a compile-time constant (10 * HZ)
with no way to change the default before the first request queue was
initialized.  Make the variable a module_param so that the override
works whether mq-deadline is built-in or compiled as a module, and
convert the millisecond value to jiffies in dd_init_sched() when
assigning the per-queue default.

Signed-off-by: Ye Bin <yebin10@huawei.com>
@blktests-ci

blktests-ci Bot commented Aug 20, 2026

Copy link
Copy Markdown
Author

Upstream branch: bd5f485
series: https://patchwork.kernel.org/project/linux-block/list/?series=1148773
version: 1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants