From: Wen Xiong <wenxiong@linux.ibm.com>
To: linux-block@vger.kernel.org, axboe@kernel.dk
Cc: tom.leiming@gmail.com, jmoyer@redhat.com,
Gjoyce <gjoyce@linux.ibm.com>,
wenxiong@us.ibm.com
Subject: Observing higher CPU utilization during random IO fio testing
Date: Thu, 21 May 2026 14:44:22 -0500 [thread overview]
Message-ID: <338169f719c77e4afe58f42e9760349e@linux.ibm.com> (raw)
Hi All,
Our performance team observed the higher CPU utilization in RHEL10
compared to RHEL9.8, observed the similar issue in upstream
kernel(v7.1-rc4) as well when running FIO random IO tests.
System configuration:
47 dedicate cores
120 GB memory
PCIe4 2-Port 64Gb FC Adapter
FlashSystem: FS9500, 12 LUNs/FC port, 100G each LUN.
Random IO tests are more CPU intensive than sequential IO tests due to
several factors: more context switching, Interrupt Handling, cache
Inefficiency etc. We found out the following patch which caused the
higher CPU utilization in rhel10 and newer linux kernel:
commit 060406c61c7cb4bbd82a02d179decca9c9bb3443 (HEAD)
Author: Yu Kuai <yukuai3@huawei.com>
Date: Thu May 9 20:38:25 2024 +0800
block: add plug while submitting IO
So that if caller didn't use plug, for example,
__blkdev_direct_IO_simple()
and __blkdev_direct_IO_async(), block layer can still benefit from
caching
nsec time in the plug.
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Link:
https://lore.kernel.org/r/20240509123825.3225207-1-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
We reverted above patch in rhel10 kernel and upstream 7.1-rc4, saw lower
CPU utilization when doing the same FIO test.
The patch adds plugging in __submit_bio() in block layer, maybe cause
performance degradation:
- Random IO tests have less merging, flush overhead.
- More IO scheduler interaction, forces requests through scheduler
instead of direct dispatch(direct dispatch to hardware queue)
- Poor cache locality during plug operation
Below are some performance data that our performance team collected:
RHEL9.8 comparison RHEL10.0
Iotype qd nj rmix mpstat busy delta lparstat
delta
Randrw 1 20 100 135% 109%
Randrw 1 40 100 72% 81%
Randrw 1 20 70 278% 174%
Randrw 1 40 70 272% 191%
Randrw 1 20 0 93% 30%
Randrw 1 40 0 104% 36%
RHEL 9.8 comparison RHEL10 with reverting above plugging patch in block
layer.h
Iotype qd nj rmix mpstat busy delta lparstat
deltab
Randrw 1 20 100 -12% 20%
Randrw 1 40 100 -42% -4%
Randrw 1 20 70 70% 71%
Randrw 1 40 70 %51 60%
Randrw 1 20 0 -14% -43%
Randrw 1 40 0 -33% -51%
Can a block layer expert help us resolve this high CPU utilization
performance issue?
Let us know if you need more performance data or other perf data.
Thanks a lot for your help!
Wendy
next reply other threads:[~2026-05-21 19:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-21 19:44 Wen Xiong [this message]
2026-05-21 21:52 ` Observing higher CPU utilization during random IO fio testing Jens Axboe
2026-05-25 5:28 ` Yu Kuai
2026-05-26 15:28 ` Wen Xiong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=338169f719c77e4afe58f42e9760349e@linux.ibm.com \
--to=wenxiong@linux.ibm.com \
--cc=axboe@kernel.dk \
--cc=gjoyce@linux.ibm.com \
--cc=jmoyer@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=tom.leiming@gmail.com \
--cc=wenxiong@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox