mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: 周泰宇 <zhoutaiyu@kuaishou.com>
To: Yu Kuai <yukuai1@huaweicloud.com>, "tj@kernel.org" <tj@kernel.org>
Cc: "josef@toxicpanda.com" <josef@toxicpanda.com>,
	"axboe@kernel.dk" <axboe@kernel.dk>,
	"cgroups@vger.kernel.org" <cgroups@vger.kernel.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"yukuai (C)" <yukuai3@huawei.com>
Subject: Re: [PATCH] blk-throttle: fix repeat limit on bio with BIO_BPS_THROTTLED
Date: Mon, 22 Apr 2024 13:05:08 +0000	[thread overview]
Message-ID: <2b492386e60c4819ac694a65de9b5846@kuaishou.com> (raw)
In-Reply-To: <6ab1172f-2c9a-ede3-8020-13c73b91db84@huaweicloud.com>

Hi, kuai

Thank you so much for your feedback.

> The ponit here is that you break the rules about FIFO, blk-throttle
> only judge the bio from head if it's within limit. Current code to judge
> if tg iops reaches limit on the condition that no bio is throttled. And
> throtl time is always caculated by first throttled bio. But this patch
> will ignore throttled bio case, and that's why I said IO will not be
> throttled by iops limist anymore. You can test this with bps limit
> disabled.

Sorry, I don't get it.  Yes, I know this patch will break the FIFO rule.
But I didn't find any problems after letting split bio break this rule. 
I think the split bio should be ignored if it does not
make the tg out of iops limit and be judged in tg_within_iops_limit().

In the patch, split bio within iops limit  will be dispatched directly.
However, if the split bio makes a tg out of IOPS limit, the split bio will be throttled 
and be added to the tg's sq->queue[rw] by calling throtl_add_bio_tg().

There exists two cases after the split bio is judged to be throttled.

1) The tg->sq->queue is empty. In this case, the split bio will be the first queued bio.  The tg's 
latest dispatch time is calculated according to the split bio by calling tg_update_disptime(), and 
the dispatch timer is waked up by calling throtl_schedule_next_dispatch().

2) The tg->sq->queue is not empty. In this case, the tg's dispatch time has been updated
according to the first queued bio and the dispatch timer is also waked up.
So, blk-throttle just adds the split bio to the tail of the sq->queue[rw] which acts like
the current code (split bio is throttled because sq->nr_queue[rw] is not zero).


I have tested this patch by only setting iops limit as you advised, with following scripts

#!/bin/bash

CNUM=30
mkdir -p /sys/fs/cgroup/blkio/test0
#echo "8:16 10485760" > /sys/fs/cgroup/blkio/test0/blkio.throttle.write_bps_device
echo "8:16 50" > /sys/fs/cgroup/blkio/test0/blkio.throttle.write_iops_device

for ((i=0;i<$CNUM;i++));do
        fio -rw=write -direct=1 -bs=4M -iodepth=8 -size=200M -numjobs=1 -time_based=1 -runtime=110  -name=testt_$i -filename=testf_$i  > /dev/null &
        echo $! > /sys/fs/cgroup/blkio/test0/tasks
done

I monitor the w/s on iostat and the change of /sys/fs/cgroup/blkio/test0/blkio.throttle.io_serviced every second.
It seems work perfectly (around 50).  

I also see the split bio be throttled through the trace_pipe

    kworker/19:2-1603    [019] d..1.   583.556012:   8,16   X  WS 977153216 / 977155776 [kworker/19:2]
    kworker/19:2-1603    [019] d..1.   583.556012:   8,16  1,0  m   N throtl [W] bio. bdisp=0 sz=1572864 bps=18446744073709551615 iodisp=5 iops=50 queued=0/28
    ......
    kworker/19:2-1603    [019] d..1.   583.556017:   8,16   X  WS 1870472 / 1873032 [kworker/19:2]
    kworker/19:2-1603    [019] d..1.   583.556018:   8,16  1,0  m   N throtl [W] bio. bdisp=0 sz=1572864 bps=18446744073709551615 iodisp=5 iops=50 queued=0/29

Would you mind give me more hints to find out the problems of my patch or try my patch? 

Sincerely,
Taiyu Zhou

      reply	other threads:[~2024-04-22 13:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-19 12:07 zhoutaiyu
2024-04-20  1:48 ` Yu Kuai
2024-04-22  3:33   ` 周泰宇
2024-04-22  3:47     ` Yu Kuai
2024-04-22 17:39       ` tj
2024-04-23  1:50         ` Yu Kuai
2024-04-23  2:29           ` 周泰宇
2024-04-22  9:42     ` Yu Kuai
2024-04-22 13:05       ` 周泰宇 [this message]

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=2b492386e60c4819ac694a65de9b5846@kuaishou.com \
    --to=zhoutaiyu@kuaishou.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=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

all inboxes | Powered by JetHome®