lkml.org 
[lkml]   [2026]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
Subject[BUG] procs_blocked / PSI io pressure stuck high from boot with zero tasks in D state
Hi,

I'm hitting what looks like a kernel accounting bug where nr_iowait /
procs_blocked and PSI io pressure are pinned high from the moment the
system boots, with no tasks actually blocked on I/O and no real device
activity to explain it.

## System
- Kernel: 7.0.0-rc7 vanilla
(7.0.0-0.rc7.260409.7f87a5ea.256.vanilla.fc43.x86_64)
- Also reproduces on the stock Fedora 43 kernel I was running before
switching to the vanilla 7.0-rc series — this is not a 7.0-rc
regression, it's longer-standing.
- CPU: AMD Ryzen 9 7900 (Raphael), 24 threads
- Board: ASUS PRIME B650-PLUS
- Distro: Fedora 43, GNOME on Wayland
- Root FS: ext4 on NVMe (Corsair MP600 Pro)
- Also mounted: btrfs on SATA

## Symptom

From boot, with the machine otherwise idle:

$ grep procs /proc/stat
procs_running 1
procs_blocked 4

$ cat /proc/pressure/io
some avg10=82.78 avg60=83.13 avg300=80.96 total=19613045470
full avg10=81.76 avg60=81.74 avg300=79.26 total=19138664524

$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system--
-------cpu-------
r b swpd free buff cache si so bi bo in cs
us sy id wa st
0 4 0 45064848 624228 10139452 0 0 107 274 4468 5
2 1 80 17 0
0 4 0 45072984 624228 10136356 0 0 0 0 14842 14678
1 1 82 16 0
0 4 0 45072264 624228 10136356 0 0 0 0 12841 13445
1 1 82 16 0
0 4 0 45080972 624228 10136356 0 0 0 0 13930 14327
1 1 82 16 0
0 4 0 45081692 624228 10136356 0 0 0 28 13537 13828
1 1 82 16 0

b=4, wa=16-17%, but bi/bo are zero across every sample after the first.

iostat -x 1 confirms no actual device activity anywhere:

avg-cpu: %user %nice %system %iowait %steal %idle
1.13 0.00 0.46 17.39 0.00 82.09
Device r/s rkB/s w/s wkB/s aqu-sz %util
nvme0n1 0.00 0.00 0.00 0.00 0.00 0.00
sda 0.00 0.00 0.00 0.00 0.00 0.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00
zram0 0.00 0.00 0.00 0.00 0.00 0.00

And critically - there is nothing actually in D state to account for
procs_blocked=4:

$ ps -eL -o pid,tid,stat,wchan:40,comm | awk '$3 ~ /D/'
(no output)

Nothing at the process level either. The counter is stuck, and it's
stuck at a value (4) higher than any real count I can find anywhere in
the system.

## Reproduction

100% reproducible on this machine: boot, wait for the desktop, check
/proc/stat. procs_blocked is already non-zero. It only grows, never
decays - current uptime is 15h40m and the counter has been >= 4 the
whole time. PSI io "some" and "full" both sit around 80%+
indefinitely.

Workload during reproduction is a plain idle GNOME session (Chrome, a
few terminals). Load average 0.40. No hung-task warnings in dmesg,
kernel log is otherwise clean.

## What I've ruled out

- Not a stuck userspace task - nothing in D state at process or thread
level (ps -eL -o stat).
- Not a stuck kernel thread - same check covers kthreads.
- Not real device pressure - iostat shows 0.00 %util across nvme, both
SATA disks, and zram across sustained 1s samples.
- Not hung-task related - no "INFO: task ... blocked for more than"
warnings in dmesg.
- Not cgroup-scoped weirdness - both /proc/pressure/io (system-wide)
and /proc/stat show it.
- Not a display/compositor artifact - reproduces on a cold boot to a
TTY before GNOME starts.
- Not a 7.0-rc regression - reproduces identically on the previous
Fedora 43 6.19 kernel(s) .

## Impact

top, htop, and any monitoring reading PSI all show bogus I/O pressure
from boot. More importantly, anything making scheduling or throttling
decisions based on PSI - systemd-oomd especially, which uses PSI io
and memory thresholds to decide when to kill processes - could easily
misbehave on this system.

Thanks,
Martin

\
 
 \ /
  Last update: 2026-04-10 18:24    [W:0.057 / U:10.970 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and my Meterkast|Read the blog