From: Ming Lei <ming.lei@redhat.com>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: Tejun Heo <tj@kernel.org>,
axboe@kernel.dk, josef@toxicpanda.com,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org, yi.zhang@huawei.com,
yangerkun@huawei.com, "yukuai (C)" <yukuai3@huawei.com>
Subject: Re: [PATCH] blk-throttle: support io merge over iops_limit
Date: Mon, 10 Mar 2025 10:16:46 +0800 [thread overview]
Message-ID: <Z85LjhvkCzlqBVZy@fedora> (raw)
In-Reply-To: <5fc124c9-e202-99ca-418d-0f52d027640f@huaweicloud.com>
On Mon, Mar 10, 2025 at 09:58:57AM +0800, Yu Kuai wrote:
> Hi,
>
> 在 2025/03/08 0:07, Tejun Heo 写道:
> > Hello,
> >
> > On Fri, Mar 07, 2025 at 05:01:52PM +0800, Yu Kuai wrote:
> > > From: Yu Kuai <yukuai3@huawei.com>
> > >
> > > Commit 9f5ede3c01f9 ("block: throttle split bio in case of iops limit")
> > > support to account split IO for iops limit, because block layer provides
> > > io accounting against split bio.
> > >
> > > However, io merge is still not handled, while block layer doesn't
> > > account merged io for iops. Fix this problem by decreasing io_disp
> > > if bio is merged, and following IO can use the extra budget. If io merge
> > > concurrent with iops throttling, it's not handled if one more or one
> > > less bio is dispatched, this is fine because as long as new slice is not
> > > started, blk-throttle already preserve one extra slice for deviation,
> > > and it's not worth it to handle the case that iops_limit rate is less than
> > > one per slice.
> > >
> > > A regression test will be added for this case [1], before this patch,
> > > the test will fail:
> > >
> > > +++ /root/blktests-mainline/results/nodev/throtl/007.out.bad
> > > @@ -1,4 +1,4 @@
> > > Running throtl/007
> > > 1
> > > -1
> > > +11
> > > Test complete
> > >
> > > [1] https://lore.kernel.org/all/20250307080318.3860858-2-yukuai1@huaweicloud.com/
> >
> > For blk-throtl, iops limit has meant the number of bios issued. I'm not
>
> Yes, but it's a litter hard to explain to users the differece between IO
> split and IO merge, they just think IO split is the numer of IOs issued
> to disk, and IO merge is the number of IOs issued from user.
Here it is really one trouble.
a) Sometimes people think IOs wrt. IOPS means that the read/write IO
submitted from application, one typical example is `fio`.
b) Sometimes people think it is the data observed from `iostat`.
In a), io merge/split isn't taken into account, but b) does cover io
merge and split.
So question is that what is the correct way for user to observe IOPS
wrt. iops throttle?
Thanks,
Ming
next prev parent reply other threads:[~2025-03-10 2:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-07 9:01 [PATCH] blk-throttle: support io merge over iops_limit Yu Kuai
2025-03-07 16:07 ` Tejun Heo
2025-03-10 1:58 ` Yu Kuai
2025-03-10 2:16 ` Ming Lei [this message]
2025-03-10 15:53 ` Tejun Heo
2025-03-11 3:08 ` Yu Kuai
2025-03-11 19:34 ` Tejun Heo
2025-03-12 1:51 ` Yu Kuai
2025-03-12 15:41 ` Tejun Heo
2025-03-24 2:06 ` Yu Kuai
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=Z85LjhvkCzlqBVZy@fedora \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=josef@toxicpanda.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai1@huaweicloud.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