From: Yu Kuai <yukuai3@huawei.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>, <yi.zhang@huawei.com> Subject: [PATCH -next 00/11] support concurrent sync io for bfq on a specail occasion Date: Sat, 5 Mar 2022 17:11:54 +0800 [thread overview] Message-ID: <20220305091205.4188398-1-yukuai3@huawei.com> (raw) 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(). This patchset tries to support concurrent sync io if all the sync ios are issued from the same cgroup: 1) Count root_group into 'num_groups_with_pending_reqs', patch 1-5; 2) Don't idle if 'num_groups_with_pending_reqs' is 1, patch 6; 3) Don't count the group if the group doesn't have pending requests, while it's child groups may have pending requests, patch 7; This is because, for example: if sync ios are issued from cgroup /root/c1/c2, root, c1 and c2 will all be counted into 'num_groups_with_pending_reqs', which makes it impossible to handle sync ios concurrently. 4) Decrease 'num_groups_with_pending_reqs' when the last queue completes all the requests, while child groups may still have pending requests, patch 8-10; This is because, for example: t1 issue sync io on root group, t2 and t3 issue sync io on the same child group. num_groups_with_pending_reqs is 2 now. After t1 stopped, num_groups_with_pending_reqs is still 2. sync io from t2 and t3 still can't be handled concurrently. fio test script: startdelay is used to avoid queue merging [global] filename=/dev/nvme0n1 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.17-rc6: 550 Mib/s v5.17-rc6-patched: 550 Mib/s running fio on non-root cgroup v5.17-rc6: 349 Mib/s v5.17-rc6-patched: 550 Mib/s Yu Kuai (11): block, bfq: add new apis to iterate bfq entities block, bfq: apply news apis where root group is not expected block, bfq: cleanup for __bfq_activate_requeue_entity() block, bfq: move the increasement of 'num_groups_with_pending_reqs' to it's caller block, bfq: count root group into 'num_groups_with_pending_reqs' block, bfq: do not idle if only one cgroup is activated block, bfq: only count parent bfqg when bfqq is activated block, bfq: record how many queues have pending requests in bfq_group block, bfq: move forward __bfq_weights_tree_remove() block, bfq: decrease 'num_groups_with_pending_reqs' earlier block, bfq: cleanup bfqq_group() block/bfq-cgroup.c | 13 +++---- block/bfq-iosched.c | 87 +++++++++++++++++++++++---------------------- block/bfq-iosched.h | 41 +++++++++++++-------- block/bfq-wf2q.c | 56 +++++++++++++++-------------- 4 files changed, 106 insertions(+), 91 deletions(-) -- 2.31.1
WARNING: multiple messages have this Message-ID (diff)
From: Yu Kuai <yukuai3@huawei.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, yi.zhang@huawei.com Subject: [PATCH -next 00/11] support concurrent sync io for bfq on a specail occasion Date: Sat, 5 Mar 2022 17:11:54 +0800 [thread overview] Message-ID: <20220305091205.4188398-1-yukuai3@huawei.com> (raw) 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(). This patchset tries to support concurrent sync io if all the sync ios are issued from the same cgroup: 1) Count root_group into 'num_groups_with_pending_reqs', patch 1-5; 2) Don't idle if 'num_groups_with_pending_reqs' is 1, patch 6; 3) Don't count the group if the group doesn't have pending requests, while it's child groups may have pending requests, patch 7; This is because, for example: if sync ios are issued from cgroup /root/c1/c2, root, c1 and c2 will all be counted into 'num_groups_with_pending_reqs', which makes it impossible to handle sync ios concurrently. 4) Decrease 'num_groups_with_pending_reqs' when the last queue completes all the requests, while child groups may still have pending requests, patch 8-10; This is because, for example: t1 issue sync io on root group, t2 and t3 issue sync io on the same child group. num_groups_with_pending_reqs is 2 now. After t1 stopped, num_groups_with_pending_reqs is still 2. sync io from t2 and t3 still can't be handled concurrently. fio test script: startdelay is used to avoid queue merging [global] filename=/dev/nvme0n1 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.17-rc6: 550 Mib/s v5.17-rc6-patched: 550 Mib/s running fio on non-root cgroup v5.17-rc6: 349 Mib/s v5.17-rc6-patched: 550 Mib/s Yu Kuai (11): block, bfq: add new apis to iterate bfq entities block, bfq: apply news apis where root group is not expected block, bfq: cleanup for __bfq_activate_requeue_entity() block, bfq: move the increasement of 'num_groups_with_pending_reqs' to it's caller block, bfq: count root group into 'num_groups_with_pending_reqs' block, bfq: do not idle if only one cgroup is activated block, bfq: only count parent bfqg when bfqq is activated block, bfq: record how many queues have pending requests in bfq_group block, bfq: move forward __bfq_weights_tree_remove() block, bfq: decrease 'num_groups_with_pending_reqs' earlier block, bfq: cleanup bfqq_group() block/bfq-cgroup.c | 13 +++---- block/bfq-iosched.c | 87 +++++++++++++++++++++++---------------------- block/bfq-iosched.h | 41 +++++++++++++-------- block/bfq-wf2q.c | 56 +++++++++++++++-------------- 4 files changed, 106 insertions(+), 91 deletions(-) -- 2.31.1
next reply other threads:[~2022-03-05 8:56 UTC|newest] Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-05 9:11 Yu Kuai [this message] 2022-03-05 9:11 ` [PATCH -next 00/11] support concurrent sync io for bfq on a specail occasion Yu Kuai 2022-03-05 9:11 ` [PATCH -next 01/11] block, bfq: add new apis to iterate bfq entities Yu Kuai 2022-03-05 9:11 ` Yu Kuai 2022-03-05 9:11 ` [PATCH -next 02/11] block, bfq: apply news apis where root group is not expected Yu Kuai 2022-03-05 9:11 ` Yu Kuai 2022-04-13 9:50 ` Jan Kara 2022-04-13 10:59 ` Jan Kara 2022-04-13 11:11 ` yukuai (C) 2022-04-13 11:11 ` yukuai (C) 2022-03-05 9:11 ` [PATCH -next 03/11] block, bfq: cleanup for __bfq_activate_requeue_entity() Yu Kuai 2022-03-05 9:11 ` Yu Kuai 2022-03-05 9:11 ` [PATCH -next 04/11] block, bfq: move the increasement of 'num_groups_with_pending_reqs' to it's caller Yu Kuai 2022-03-05 9:11 ` Yu Kuai 2022-03-05 9:11 ` [PATCH -next 05/11] block, bfq: count root group into 'num_groups_with_pending_reqs' Yu Kuai 2022-03-05 9:11 ` Yu Kuai 2022-04-13 11:05 ` Jan Kara 2022-04-13 11:05 ` Jan Kara 2022-03-05 9:12 ` [PATCH -next 06/11] block, bfq: do not idle if only one cgroup is activated Yu Kuai 2022-03-05 9:12 ` Yu Kuai 2022-03-05 9:12 ` [PATCH -next 07/11] block, bfq: only count parent bfqg when bfqq " Yu Kuai 2022-03-05 9:12 ` Yu Kuai 2022-03-05 9:12 ` [PATCH -next 08/11] block, bfq: record how many queues have pending requests in bfq_group Yu Kuai 2022-03-05 9:12 ` Yu Kuai 2022-03-05 9:12 ` [PATCH -next 09/11] block, bfq: move forward __bfq_weights_tree_remove() Yu Kuai 2022-03-05 9:12 ` Yu Kuai 2022-03-05 9:12 ` [PATCH -next 10/11] block, bfq: decrease 'num_groups_with_pending_reqs' earlier Yu Kuai 2022-03-05 9:12 ` Yu Kuai 2022-04-13 11:28 ` Jan Kara 2022-04-13 11:40 ` yukuai (C) 2022-04-13 11:40 ` yukuai (C) 2022-04-15 1:10 ` yukuai (C) 2022-04-15 1:10 ` yukuai (C) 2022-04-19 9:49 ` Jan Kara 2022-04-19 9:49 ` Jan Kara 2022-04-19 11:37 ` yukuai (C) 2022-04-19 11:37 ` yukuai (C) 2022-04-21 8:17 ` Jan Kara 2022-04-21 8:17 ` Jan Kara 2022-03-05 9:12 ` [PATCH -next 11/11] block, bfq: cleanup bfqq_group() Yu Kuai 2022-03-05 9:12 ` Yu Kuai 2022-03-11 6:31 ` [PATCH -next 00/11] support concurrent sync io for bfq on a specail occasion yukuai (C) 2022-03-11 6:31 ` yukuai (C) 2022-03-17 1:49 ` yukuai (C) 2022-03-17 1:49 ` yukuai (C) 2022-03-18 12:38 ` Paolo Valente 2022-03-19 2:34 ` yukuai (C) 2022-03-19 2:34 ` yukuai (C) 2022-03-25 7:30 ` yukuai (C) 2022-03-25 7:30 ` yukuai (C) 2022-04-01 3:43 ` yukuai (C) 2022-04-01 3:43 ` yukuai (C) 2022-04-08 6:50 ` yukuai (C) 2022-04-08 6:50 ` yukuai (C) 2022-04-13 11:12 ` Jan Kara 2022-04-13 11:12 ` Jan Kara 2022-04-13 11:33 ` yukuai (C) 2022-04-13 11:33 ` yukuai (C) 2022-04-26 14:24 ` Paolo Valente
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=20220305091205.4188398-1-yukuai3@huawei.com \ --to=yukuai3@huawei.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 \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.