All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joseph Qi <jiangqi903@gmail.com>
To: 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>
Subject: Re: testing io.low limit for blk-throttle
Date: Mon, 23 Apr 2018 14:05:51 +0800	[thread overview]
Message-ID: <4c6b86d9-1668-43c3-c159-e6e23ffb04b4@gmail.com> (raw)
In-Reply-To: <A749046B-BEB9-4278-ABEF-3007817D59DD@linaro.org>

Hi Paolo,
What's your idle and latency config?
IMO, io.low will allow others run more bandwidth if cgroup's average
idle time is high or latency is low. In such cases, low limit won't get
guaranteed.

Thanks,
Joseph

On 18/4/22 17:23, Paolo Valente wrote:
> Hi Shaohua, all,
> at last, I started testing your io.low limit for blk-throttle.  One of
> the things I'm interested in is how good throttling is in achieving a
> high throughput in the presence of realistic, variable workloads.
> 
> However, I seem to have bumped into a totally different problem.  The
> io.low parameter doesn't seem to guarantee what I understand it is meant
> to guarantee: minimum per-group bandwidths.  For example, with
> - one group, the interfered, containing one process that does sequential
>   reads with fio
> - io.low set to 100MB/s for the interfered
> - six other groups, the interferers, with each interferer containing one
>   process doing sequential read with fio
> - io.low set to 10MB/s for each interferer
> - the workload executed on an SSD, with a 500MB/s of overall throughput
> the interfered gets only 75MB/s.
> 
> In particular, the throughput of the interfered becomes lower and
> lower as the number of interferers is increased.  So you can make it
> become even much lower than the 75MB/s in the example above.  There
> seems to be no control on bandwidth.
> 
> Am I doing something wrong?  Or did I simply misunderstand the goal of
> io.low, and the only parameter for guaranteeing the desired bandwidth to
> a group is io.max (to be used indirectly, by limiting the bandwidth of
> the interferers)?
> 
> If useful for you, you can reproduce the above test very quickly, by
> using the S suite [1] and typing:
> 
> cd thr-lat-with-interference
> sudo ./thr-lat-with-interference.sh -b t -w 100000000 -W "10000000 10000000 10000000 10000000 10000000 10000000" -n 6 -T "read read read read read read" -R "0 0 0 0 0 0"
> 
> Looking forward to your feedback,
> Paolo
> 
> [1] 
> 

  parent reply	other threads:[~2018-04-23  6:05 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 [this message]
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
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=4c6b86d9-1668-43c3-c159-e6e23ffb04b4@gmail.com \
    --to=jiangqi903@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=broonie@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-block@vger.kernel.org \
    --cc=paolo.valente@linaro.org \
    --cc=shli@fb.com \
    --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.