From: Xiaobing Li <[email protected]>
To: [email protected], [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected]
Cc: [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected],
[email protected], Xiaobing Li <[email protected]>
Subject: [PATCH 0/3] Sq thread real utilization statistics.
Date: Thu, 28 Sep 2023 10:22:25 +0800 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: CGME20230928023004epcas5p4a6dac4cda9c867f3673690521a8c18b6@epcas5p4.samsung.com
Summary:
The current kernel's pelt scheduling algorithm is calculated based on
the running time of the thread. However, this algorithm may cause a
waste of CPU resources for some threads, such as the sq thread in
io_uring.
Since the sq thread has a while(1) structure, during this process, there
may be a lot of time when IO is not processed but the timeout period is
not exceeded, so the sqpoll thread will keep running, thus occupying the
CPU. Obviously, the CPU is wasted at this time.
our goal is to count the part of the time the sqpoll thread actually
processes IO, thereby reflecting the part of its CPU used to process IO,
which can be used to help improve the actual utilization of the CPU in
the future.
Modifications to the scheduling module are also applicable to other
threads with the same needs.
We use fio (version 3.28) to test the performance. In the experiments,
an fio process are viewed as an application, it starts job with sq_poll
enabled. The tests are performed on a host with 256 CPUs and 64G memory,
the IO tasks are performed on a PM1743 SSD, and the OS is Ubuntu 22.04
with kernel version of 6.4.0.
Some parameters for sequential reading and writing are as follows:
bs=128k, numjobs=1, iodepth=64.
Some parameters for random reading and writing are as follows:
bs=4k, numjobs=16, iodepth=64.
The test results are as follows:
Before modification
read write randread randwrite
IOPS(K) 53.7 46.1 849 293
BW(MB/S) 7033 6037 3476 1199
After modification
read write randread randwrite
IOPS(K) 53.7 46.1 847 293
BW(MB/S) 7033 6042 3471 1199
It can be seen from the test results that my modifications have almost
no impact on performance.
Xiaobing Li (3):
SCHEDULER: Add an interface for counting real utilization.
PROC FILESYSTEM: Add real utilization data of sq thread.
IO_URING: Statistics of the true utilization of sq threads.
fs/proc/stat.c | 25 ++++++++++++++++++++++++-
include/linux/kernel.h | 7 ++++++-
include/linux/kernel_stat.h | 3 +++
include/linux/sched.h | 1 +
io_uring/sqpoll.c | 26 +++++++++++++++++++++++++-
kernel/sched/cputime.c | 36 +++++++++++++++++++++++++++++++++++-
kernel/sched/pelt.c | 14 ++++++++++++++
7 files changed, 108 insertions(+), 4 deletions(-)
--
2.34.1
next parent reply other threads:[~2023-09-28 2:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20230928023004epcas5p4a6dac4cda9c867f3673690521a8c18b6@epcas5p4.samsung.com>
2023-09-28 2:22 ` Xiaobing Li [this message]
[not found] ` <CGME20230928023007epcas5p276b6e029a67001a6ed8ab28c05b2be9c@epcas5p2.samsung.com>
2023-09-28 2:22 ` [PATCH 1/3] SCHEDULER: Add an interface for counting real utilization Xiaobing Li
2023-09-28 7:52 ` kernel test robot
2023-09-28 8:02 ` Peter Zijlstra
2023-09-29 0:31 ` Thomas Gleixner
[not found] ` <CGME20230928023011epcas5p32668b193b447f1cd6bf78035f4894c42@epcas5p3.samsung.com>
2023-09-28 2:22 ` [PATCH 2/3] PROC FILESYSTEM: Add real utilization data of sq thread Xiaobing Li
[not found] ` <CGME20230928023015epcas5p273b3eaebf3759790c278b03c7f0341c8@epcas5p2.samsung.com>
2023-09-28 2:22 ` [PATCH 3/3] IO_URING: Statistics of the true utilization of sq threads Xiaobing Li
2023-09-28 8:01 ` Peter Zijlstra
2023-09-28 8:23 ` Jens Axboe
2023-09-28 8:37 ` Matthew Wilcox
2023-09-28 8:41 ` Jens Axboe
2023-09-28 18:33 ` kernel test robot
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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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