All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joseph Qi <jiangqi903@gmail.com>
To: "jianchao.wang" <jianchao.w.wang@oracle.com>, Tejun Heo <tj@kernel.org>
Cc: Paolo Valente <paolo.valente@linaro.org>,
	linux-block <linux-block@vger.kernel.org>,
	Jens Axboe <axboe@kernel.dk>, Shaohua Li <shli@fb.com>,
	Mark Brown <broonie@kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: testing io.low limit for blk-throttle
Date: Fri, 27 Apr 2018 10:40:40 +0800	[thread overview]
Message-ID: <9ef3c9be-8973-33ae-6dba-c7a5af55e5ea@gmail.com> (raw)
In-Reply-To: <9aee3b22-2600-b16b-d944-f3a09089664f@oracle.com>

Hi Jianchao,

On 18/4/27 10:09, jianchao.wang wrote:
> Hi Tejun and Joseph
> 
> On 04/27/2018 02:32 AM, Tejun Heo wrote:
>> Hello,
>>
>> On Tue, Apr 24, 2018 at 02:12:51PM +0200, Paolo Valente wrote:
>>> +Tejun (I guess he might be interested in the results below)
>>
>> Our experiments didn't work out too well either.  At this point, it
>> isn't clear whether io.low will ever leave experimental state.  We're
>> trying to find a working solution.
> 
> Would you please take a look at the following two patches.
> 
> https://marc.info/?l=linux-block&m=152325456307423&w=2
> https://marc.info/?l=linux-block&m=152325457607425&w=2
> 
> In addition, when I tested blk-throtl io.low on NVMe card, I always got
> even if the iops has been lower than io.low limit for a while, but the
> due to group is not idle, the downgrade always fails.
> 
>        tg->latency_target && tg->bio_cnt &&
> 		tg->bad_bio_cnt * 5 < tg->bio_cn
> 

I'm afraid the latency check is a must for io.low. Because idle time
check can only apply to simple scenarios from my test.

Yes, in some cases last_low_overflow_time does have problems.
And for not downgrade properly, I've also posted two patches before,
waiting Shaohua's review. You can also have a try.

https://patchwork.kernel.org/patch/10177185/
https://patchwork.kernel.org/patch/10177187/

Thanks,
Joseph

> the latency always looks well even the sum of two groups's iops has reached the top.
> so I disable this check on my test, plus the 2 patches above, the io.low
> could basically works.
> 
> My NVMe card's max bps is ~600M, and max iops is ~160k.
> Here is my config
> io.low riops=50000 wiops=50000 rbps=209715200 wbps=209715200 idle=200 latency=10
> io.max riops=150000
> There are two cgroups in my test, both of them have same config.
> 
> In addition, saying "basically work" is due to the iops of the two cgroup will jump up and down.
> such as, I launched one fio test per cgroup, the iops will wave as following:
> 
> group0   30k  50k   70k   60k  40k
> group1   120k 100k  80k   90k  110k
> 
> however, if I launched two fio tests only in one cgroup, the iops of two test could stay 
> about 70k~80k.
> 
> Could help to explain this scenario ?
> 
> Thanks in advance
> Jianchao
> 

  reply	other threads:[~2018-04-27  2:40 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-22  9:23 testing io.low limit for blk-throttle Paolo Valente
2018-04-22 13:29 ` jianchao.wang
2018-04-22 15:53   ` Paolo Valente
2018-04-23  2:19     ` jianchao.wang
2018-04-23  5:32       ` Paolo Valente
2018-04-23  6:35         ` jianchao.wang
2018-04-23  7:37           ` Paolo Valente
2018-04-23  8:26             ` jianchao.wang
2018-04-23  6:05 ` Joseph Qi
2018-04-23  7:35   ` Paolo Valente
2018-04-23  9:01     ` Joseph Qi
2018-04-24 12:12       ` Paolo Valente
2018-04-24 12:12         ` Paolo Valente
2018-04-25 12:13         ` Joseph Qi
2018-04-26 17:27           ` Paolo Valente
2018-04-27  3:27             ` Joseph Qi
2018-04-27  5:14               ` Paolo Valente
2018-04-27  5:14                 ` Paolo Valente
2018-04-26 18:32         ` Tejun Heo
2018-04-27  2:09           ` jianchao.wang
2018-04-27  2:40             ` Joseph Qi [this message]
2018-05-03 16:35           ` Paolo Valente
2018-05-03 16:35             ` 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=9ef3c9be-8973-33ae-6dba-c7a5af55e5ea@gmail.com \
    --to=jiangqi903@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=broonie@kernel.org \
    --cc=jianchao.w.wang@oracle.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paolo.valente@linaro.org \
    --cc=shli@fb.com \
    --cc=tj@kernel.org \
    --cc=ulf.hansson@linaro.org \
    /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.