[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250530080355.1138759-1-yukuai1@huaweicloud.com>
Date: Fri, 30 May 2025 16:03:51 +0800
From: Yu Kuai <yukuai1@...weicloud.com>
To: axboe@...nel.dk
Cc: linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org,
yukuai3@...wei.com,
yukuai1@...weicloud.com,
yi.zhang@...wei.com,
yangerkun@...wei.com,
johnny.chenyi@...wei.com
Subject: [PATCH RFC 0/4] blk-mq-sched: support request batch dispatching for sq elevator
From: Yu Kuai <yukuai3@...wei.com>
Lock contention for sq elevator is quite intense when multiple contexts
are dispatching request, main reason is that a global lock is held and
release for each request:
while
spin_lock
disaptch one request
spin_unlock
This set support request batch dispatching to reduce the lock contention
a bit.
A simple test for null_blk in my VM:
32 job randwrite
| elevator | bandwidth Mib/s |
| -------------------------- | --------------- |
| none | 813 |
| deadline before this patch | 531 |
| deadline after this patch | 689 |
The test is one-sided, however, this is just a quick test to show this
set might be meaningful. I'm sending this RFC and want to get some
feedbacks before I continue work on this set.
Noted: do not test bfq for this set, it's not changed yet(like patch 2
for deadline).
Yu Kuai (4):
elevator: introduce global lock for sq_shared elevator
mq-deadline: switch to use elevator lock
blk-mq-sched: refactor __blk_mq_do_dispatch_sched()
blk-mq-sched: support request batch dispatching for sq elevator
block/blk-mq-sched.c | 224 +++++++++++++++++++++++++++++--------------
block/blk-mq.c | 5 +-
block/blk-mq.h | 21 ++++
block/elevator.c | 1 +
block/elevator.h | 62 +++++++++++-
block/mq-deadline.c | 60 +++++-------
6 files changed, 259 insertions(+), 114 deletions(-)
--
2.39.2
Powered by blists - more mailing lists