From: Bart Van Assche <bart.vanassche@sandisk.com>
To: Shaohua Li <shli@fb.com>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Kernel-team@fb.com" <Kernel-team@fb.com>,
"axboe@fb.com" <axboe@fb.com>, "tj@kernel.org" <tj@kernel.org>,
"vgoyal@redhat.com" <vgoyal@redhat.com>
Subject: Re: [PATCH V4 00/15] blk-throttle: add .high limit
Date: Mon, 14 Nov 2016 17:18:28 -0800 [thread overview]
Message-ID: <1bf8605a-9920-19ea-e2ab-2f3d747e55be@sandisk.com> (raw)
In-Reply-To: <20161115004922.GA16173@shli-mbp.local>
On 11/14/2016 04:49 PM, Shaohua Li wrote:
> On Mon, Nov 14, 2016 at 04:41:33PM -0800, Bart Van Assche wrote:
>> Thank you for pointing me to the discussion thread about v3 of this patch
>> series. Did I see correctly that one of the conclusions was that for users
>> this mechanism is hard to configure? Are we providing a good service to
>> Linux users by providing a mechanism that is hard to configure?
>
> Yes, this is a kind of low level knob and is expected to be configured by
> experienced users. This sucks, but we really don't have good solutions. If
> anybody has better ideas, I'm happy to try.
Hello Shaohua,
An approach I have been considering to analyze further is as follows:
* For rotational media use an algorithm like BFQ to preserve
sequentiality of workloads and to guarantee fairness. This means that
one application submits I/O per time slot.
* For SSDs, multiplex I/O from multiple applications during a single
time slot to keep the queue depth high. Throttle I/O if needed to
realize fairness.
Implementing this approach requires an approach for estimating I/O cost
based on the request characteristics (offset and size) and the device
type (rotational or SSD). This may require measuring the time that was
needed to process past requests and to use that information in a
learning algorithm.
Unless someone can convince me of the opposite I think that coming up
with an algorithm for estimating I/O cost is essential to guarantee I/O
fairness without requesting users to perform complicated parameter
configurations.
Bart.
next prev parent reply other threads:[~2016-11-15 1:34 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-14 22:22 Shaohua Li
2016-11-14 22:22 ` [PATCH V4 01/15] blk-throttle: prepare support multiple limits Shaohua Li
2016-11-14 22:22 ` [PATCH V4 02/15] blk-throttle: add .high interface Shaohua Li
2016-11-22 20:02 ` Tejun Heo
2016-11-22 23:08 ` Shaohua Li
2016-11-23 21:11 ` Tejun Heo
2016-11-14 22:22 ` [PATCH V4 03/15] blk-throttle: configure bps/iops limit for cgroup in high limit Shaohua Li
2016-11-22 20:16 ` Tejun Heo
2016-11-22 23:11 ` Shaohua Li
2016-11-14 22:22 ` [PATCH V4 04/15] blk-throttle: add upgrade logic for LIMIT_HIGH state Shaohua Li
2016-11-14 22:22 ` [PATCH V4 05/15] blk-throttle: add downgrade logic Shaohua Li
2016-11-22 21:21 ` Tejun Heo
2016-11-22 21:42 ` Tejun Heo
2016-11-22 23:38 ` Shaohua Li
2016-11-14 22:22 ` [PATCH V4 06/15] blk-throttle: make sure expire time isn't too big Shaohua Li
2016-11-14 22:22 ` [PATCH V4 07/15] blk-throttle: make throtl_slice tunable Shaohua Li
2016-11-22 21:27 ` Tejun Heo
2016-11-22 23:18 ` Shaohua Li
2016-11-23 21:17 ` Tejun Heo
2016-11-14 22:22 ` [PATCH V4 08/15] blk-throttle: detect completed idle cgroup Shaohua Li
2016-11-14 22:22 ` [PATCH V4 09/15] blk-throttle: make bandwidth change smooth Shaohua Li
2016-11-23 21:23 ` Tejun Heo
2016-11-24 0:59 ` Shaohua Li
2016-11-14 22:22 ` [PATCH V4 10/15] blk-throttle: add a simple idle detection Shaohua Li
2016-11-23 21:46 ` Tejun Heo
2016-11-24 1:15 ` Shaohua Li
2016-11-28 22:21 ` Tejun Heo
2016-11-28 23:10 ` Shaohua Li
2016-11-29 17:08 ` Tejun Heo
2016-11-14 22:22 ` [PATCH V4 11/15] blk-throttle: add interface to configure think time threshold Shaohua Li
2016-11-23 21:32 ` Tejun Heo
2016-11-24 1:06 ` Shaohua Li
2016-11-28 22:08 ` Tejun Heo
2016-11-28 22:14 ` Shaohua Li
2016-11-14 22:22 ` [PATCH V4 12/15] blk-throttle: ignore idle cgroup limit Shaohua Li
2016-11-14 22:22 ` [PATCH V4 13/15] blk-throttle: add a mechanism to estimate IO latency Shaohua Li
2016-11-14 23:40 ` kbuild test robot
2016-11-15 3:57 ` kbuild test robot
2016-11-29 17:24 ` Tejun Heo
2016-11-29 18:30 ` Shaohua Li
2016-11-29 22:36 ` Tejun Heo
2016-11-14 22:22 ` [PATCH V4 14/15] blk-throttle: add interface for per-cgroup target latency Shaohua Li
2016-11-14 22:22 ` [PATCH V4 15/15] blk-throttle: add latency target support Shaohua Li
2016-11-29 17:31 ` Tejun Heo
2016-11-29 18:14 ` Shaohua Li
2016-11-29 22:54 ` Tejun Heo
2016-11-29 23:39 ` Shaohua Li
2016-11-14 22:46 ` [PATCH V4 00/15] blk-throttle: add .high limit Bart Van Assche
2016-11-15 0:05 ` Shaohua Li
2016-11-15 0:41 ` Bart Van Assche
2016-11-15 0:49 ` Shaohua Li
2016-11-15 1:18 ` Bart Van Assche [this message]
2016-11-15 1:28 ` Shaohua Li
2016-11-15 19:53 ` Bart Van Assche
2016-11-15 21:31 ` Shaohua Li
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=1bf8605a-9920-19ea-e2ab-2f3d747e55be@sandisk.com \
--to=bart.vanassche@sandisk.com \
--cc=Kernel-team@fb.com \
--cc=axboe@fb.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shli@fb.com \
--cc=tj@kernel.org \
--cc=vgoyal@redhat.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
Powered by JetHome