All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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: link
Be 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.