[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240227211152.1099534-1-axboe@kernel.dk>
Date: Tue, 27 Feb 2024 14:06:01 -0700
From: Jens Axboe <axboe@...nel.dk>
To: linux-kernel@...r.kernel.org
Cc: peterz@...radead.org,
mingo@...hat.com
Subject: [PATCHSET v2 0/2] Split iowait into two states
Hi,
This is v2 of the patch posted yesterday, where the current in_iowait
state is split into two parts:
1) The "task is sleeping waiting on IO", and would like cpufreq goodness
in terms of sleep and wakeup latencies.
2) The above, and also accounted as such in the iowait stats.
The current ->in_iowait covers both, with this series we have ->in_iowait
for step 1 above, and ->in_iowait_acct for step 2. You cannot be
->in_iowait_acct without also having ->in_iowait set.
Patch 1 is a prep patch, that turns rq->nr_iowait into an unsigned int
rather than an atomic_t. Reasons given in that patch.
Patch 2 adds the ->in_iowait_acct stage inside the current ->in_iowait
setting.
I haven't been able to properly benchmark patch 1, as the atomics are
noise in any workloads that approximate normality. I can certainly
concoct a synthetic test case if folks are interested. My gut says that
we're trading 3 fast path atomics for none, and with the 4th case
_probably_ being way less likely. There we grab the rq lock.
Comments welcome! Peter, CC'ing you since I did in the previous, feel
free to ignore.
Since v1:
- Add prep patch 1, switching nr_iowait to an unsigned int
- Modify patch 2 to not use atomic_t as well, no changes otherwise
arch/s390/appldata/appldata_base.c | 2 +-
arch/s390/appldata/appldata_os.c | 2 +-
fs/proc/stat.c | 2 +-
include/linux/sched.h | 6 ++++
include/linux/sched/stat.h | 10 ++++--
kernel/sched/core.c | 55 +++++++++++++++++++++++-------
kernel/sched/cputime.c | 2 +-
kernel/sched/sched.h | 3 +-
kernel/time/tick-sched.c | 6 ++--
9 files changed, 66 insertions(+), 22 deletions(-)
--
Jens Axboe
Powered by blists - more mailing lists