From: Yu Kuai <yukuai1@huaweicloud.com>
To: tj@kernel.org, axboe@kernel.dk, paolo.valente@linaro.org, jack@suse.cz
Cc: cgroups@vger.kernel.org, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, yukuai3@huawei.com,
yukuai1@huaweicloud.com, yi.zhang@huawei.com
Subject: [patch v11 0/6] support concurrent sync io for bfq on a specail occasion
Date: Fri, 16 Sep 2022 15:19:36 +0800 [thread overview]
Message-ID: <20220916071942.214222-1-yukuai1@huaweicloud.com> (raw)
From: Yu Kuai <yukuai3@huawei.com>
Changes in v11:
- keep the comments in bfq_weights_tree_remove() and move it to the
caller where bfqq can be freed.
- add two followed up cleanup patches.
Changes in v10:
- Add reviewed-tag for patch 2
Changes in v9:
- also update how many bfqqs have pending_reqs bfq_bfqq_move().
- fix one language in patch 4
- Add reviewed-tag for patch 1,3,4
Changes in v8:
- Instead of using whether bfqq is busy, using whether bfqq has pending
requests. As Paolo pointed out the former way is problematic.
Changes in v7:
- fix mismatch bfq_inc/del_busy_queues() and bfqq_add/del_bfqq_busy(),
also retest this patchset on v5.18 to make sure functionality is
correct.
- move the updating of 'bfqd->busy_queues' into new apis
Changes in v6:
- add reviewed-by tag for patch 1
Changes in v5:
- rename bfq_add_busy_queues() to bfq_inc_busy_queues() in patch 1
- fix wrong definition in patch 1
- fix spelling mistake in patch 2: leaset -> least
- update comments in patch 3
- add reviewed-by tag in patch 2,3
Changes in v4:
- split bfq_update_busy_queues() to bfq_add/dec_busy_queues(),
suggested by Jan Kara.
- remove unused 'in_groups_with_pending_reqs',
Changes in v3:
- remove the cleanup patch that is irrelevant now(I'll post it
separately).
- instead of hacking wr queues and using weights tree insertion/removal,
using bfq_add/del_bfqq_busy() to count the number of groups
(suggested by Jan Kara).
Changes in v2:
- Use a different approch to count root group, which is much simple.
Currently, bfq can't handle sync io concurrently as long as they
are not issued from root group. This is because
'bfqd->num_groups_with_pending_reqs > 0' is always true in
bfq_asymmetric_scenario().
The way that bfqg is counted into 'num_groups_with_pending_reqs':
Before this patchset:
1) root group will never be counted.
2) Count if bfqg or it's child bfqgs have pending requests.
3) Don't count if bfqg and it's child bfqgs complete all the requests.
After this patchset:
1) root group is counted.
2) Count if bfqg has pending requests.
3) Don't count if bfqg complete all the requests.
With the above changes, concurrent sync io can be supported if only
one group is activated.
fio test script(startdelay is used to avoid queue merging):
[global]
filename=/dev/sda
allow_mounted_write=0
ioengine=psync
direct=1
ioscheduler=bfq
offset_increment=10g
group_reporting
rw=randwrite
bs=4k
[test1]
numjobs=1
[test2]
startdelay=1
numjobs=1
[test3]
startdelay=2
numjobs=1
[test4]
startdelay=3
numjobs=1
[test5]
startdelay=4
numjobs=1
[test6]
startdelay=5
numjobs=1
[test7]
startdelay=6
numjobs=1
[test8]
startdelay=7
numjobs=1
test result:
running fio on root cgroup
v5.18: 112 Mib/s
v5.18-patched: 112 Mib/s
running fio on non-root cgroup
v5.18: 51.2 Mib/s
v5.18-patched: 112 Mib/s
Note that I also test null_blk with "irqmode=2
completion_nsec=100000000(100ms) hw_queue_depth=1", and tests show
that service guarantees are still preserved.
Previous versions:
RFC: https://lore.kernel.org/all/20211127101132.486806-1-yukuai3@huawei.com/
v1: https://lore.kernel.org/all/20220305091205.4188398-1-yukuai3@huawei.com/
v2: https://lore.kernel.org/all/20220416093753.3054696-1-yukuai3@huawei.com/
v3: https://lore.kernel.org/all/20220427124722.48465-1-yukuai3@huawei.com/
v4: https://lore.kernel.org/all/20220428111907.3635820-1-yukuai3@huawei.com/
v5: https://lore.kernel.org/all/20220428120837.3737765-1-yukuai3@huawei.com/
v6: https://lore.kernel.org/all/20220523131818.2798712-1-yukuai3@huawei.com/
v7: https://lore.kernel.org/all/20220528095020.186970-1-yukuai3@huawei.com/
Yu Kuai (6):
block, bfq: support to track if bfqq has pending requests
block, bfq: record how many queues have pending requests
block, bfq: refactor the counting of 'num_groups_with_pending_reqs'
block, bfq: do not idle if only one group is activated
block, bfq: cleanup bfq_weights_tree add/remove apis
block, bfq: cleanup __bfq_weights_tree_remove()
block/bfq-cgroup.c | 10 +++++++
block/bfq-iosched.c | 71 +++++++--------------------------------------
block/bfq-iosched.h | 30 +++++++++----------
block/bfq-wf2q.c | 69 ++++++++++++++++++++++++++-----------------
4 files changed, 76 insertions(+), 104 deletions(-)
--
2.31.1
next reply other threads:[~2022-09-16 7:09 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-16 7:19 Yu Kuai [this message]
2022-09-16 7:19 ` [patch v11 1/6] block, bfq: support to track if bfqq has pending requests Yu Kuai
2022-09-16 7:19 ` [patch v11 2/6] block, bfq: record how many queues have " Yu Kuai
2022-09-16 7:19 ` [patch v11 3/6] block, bfq: refactor the counting of 'num_groups_with_pending_reqs' Yu Kuai
2022-09-27 16:32 ` Paolo Valente
2022-09-27 16:33 ` Paolo VALENTE
2022-09-16 7:19 ` [patch v11 4/6] block, bfq: do not idle if only one group is activated Yu Kuai
2022-09-16 7:19 ` [patch v11 5/6] block, bfq: cleanup bfq_weights_tree add/remove apis Yu Kuai
2022-09-19 8:46 ` Jan Kara
2022-09-27 16:19 ` Paolo Valente
2022-09-16 7:19 ` [patch v11 6/6] block, bfq: cleanup __bfq_weights_tree_remove() Yu Kuai
2022-09-27 16:38 ` [patch v11 0/6] support concurrent sync io for bfq on a specail occasion Paolo Valente
2022-09-28 1:07 ` Yu Kuai
2022-10-11 8:11 ` Yu Kuai
2022-10-11 8:21 ` Paolo Valente
2022-10-11 9:36 ` Yu Kuai
2022-10-18 4:00 ` Yu Kuai
2022-10-25 6:34 ` Paolo VALENTE
2022-10-25 7:31 ` Yu Kuai
2022-11-01 11:32 ` Yu Kuai
2022-11-01 13:10 ` Jens Axboe
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=20220916071942.214222-1-yukuai1@huaweicloud.com \
--to=yukuai1@huaweicloud.com \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paolo.valente@linaro.org \
--cc=tj@kernel.org \
--cc=yi.zhang@huawei.com \
--cc=yukuai3@huawei.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;
as well as URLs for NNTP newsgroup(s).