From: "Michal Koutný" <mkoutny@suse.com>
To: Tejun Heo <tj@kernel.org>
Cc: hannes@cmpxchg.org, clm@fb.com, dennisz@fb.com,
Josef Bacik <jbacik@fb.com>,
kernel-team@fb.com, newella@fb.com, lizefan@huawei.com,
axboe@kernel.dk, Paolo Valente <paolo.valente@linaro.org>,
Rik van Riel <riel@surriel.com>,
josef@toxicpanda.com, cgroups@vger.kernel.org,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 08/10] blkcg: implement blk-iocost
Date: Fri, 1 Nov 2019 17:15:06 +0100 [thread overview]
Message-ID: <20191101161506.GA28212@blackbody.suse.cz> (raw)
In-Reply-To: <20191014153643.GD18794@devbig004.ftw2.facebook.com>
[-- Attachment #1: Type: text/plain, Size: 2053 bytes --]
Hello
(I realize it's likely late for the remark but I'd like to bring it up
anyway.)
On Mon, Oct 14, 2019 at 08:36:43AM -0700, Tejun Heo <tj@kernel.org> wrote:
> We likely can talk on the subject
> for a really long time probalby because there's no clearly technically
> better choice here, so...
I agree with you that functionally the two options are equal and also
from configuration POV they seem both sensible.
I checked where BFQ stores its per-device parameters and its under the
sysfs directory of given device's iosched directory. So from the user
perspective it'd be more consistent if all similar tunables resided
under that location.
(OTOH, I admit I'm not that familiar with block layer internals to
identify the overlap between IO scheduler and IO controller.)
> Yeah, it's kinda unfortunate that it requires this many parameters but
> at least my opinion is that that's reflecting the inherent
> complexities of the underlying devices and how workloads interact with
> them.
After I learnt about the existence of BFQ tunables, I'm no longer
concerned by the complexity of the parameter space.
Thanks for the explanations of QoS purpose.
> For QoS parameters, Andy is currently working on a method to determine
> the set of parametesr which are at the edge of total work cliff -
> ie. the point where tighetning QoS params further starts reducing the
> total amount of work the device can do significantly.
The QoS description in the Documentation/ describes the interpretation
of the individual parameters, however, this purpose and how it works was
not clear to be from that. I think the QoS policy would deserve similar
description in the Documentation/.
> Nothing can issue IOs indefinitely without some of them completing and
> the total amount of work a workload can do is conjoined with the
> completion latencies. [...]
I may reply to this point later. However, if that provably works, I'm
likely missing something in my understanding, so that'd be irrelevant.
Cheers,
Michal
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-11-01 16:15 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-28 22:05 [PATCHSET v3 block/for-linus] IO cost model based work-conserving porportional controller Tejun Heo
2019-08-28 22:05 ` [PATCH 01/10] blkcg: pass @q and @blkcg into blkcg_pol_alloc_pd_fn() Tejun Heo
2019-08-28 22:05 ` [PATCH 02/10] blkcg: make ->cpd_init_fn() optional Tejun Heo
2019-08-28 22:05 ` [PATCH 03/10] blkcg: separate blkcg_conf_get_disk() out of blkg_conf_prep() Tejun Heo
2019-08-28 22:05 ` [PATCH 04/10] block/rq_qos: add rq_qos_merge() Tejun Heo
2019-08-28 22:05 ` [PATCH 05/10] block/rq_qos: implement rq_qos_ops->queue_depth_changed() Tejun Heo
2019-08-28 22:05 ` [PATCH 06/10] blkcg: s/RQ_QOS_CGROUP/RQ_QOS_LATENCY/ Tejun Heo
2019-08-28 22:05 ` [PATCH 07/10] blk-mq: add optional request->alloc_time_ns Tejun Heo
2019-08-28 22:05 ` [PATCH 08/10] blkcg: implement blk-iocost Tejun Heo
2019-08-29 15:53 ` [PATCH] blkcg: fix missing free on error path of blk_iocost_init() Tejun Heo
2019-09-10 12:55 ` [PATCH 08/10] blkcg: implement blk-iocost Michal Koutný
2019-09-10 16:08 ` Tejun Heo
2019-09-11 8:18 ` Paolo Valente
2019-09-11 14:16 ` Tejun Heo
2019-09-11 15:54 ` Tejun Heo
2019-09-11 16:44 ` Paolo Valente
2019-10-03 14:51 ` Michal Koutný
2019-10-03 16:45 ` Tejun Heo
2019-10-09 15:36 ` Michal Koutný
2019-10-14 15:36 ` Tejun Heo
2019-11-01 16:15 ` Michal Koutný [this message]
2019-11-01 16:56 ` Paolo Valente
2019-08-28 22:05 ` [PATCH 09/10] blkcg: add tools/cgroup/iocost_monitor.py Tejun Heo
2019-08-28 22:06 ` [PATCH 10/10] blkcg: add tools/cgroup/iocost_coef_gen.py Tejun Heo
2019-08-29 3:29 ` [PATCHSET v3 block/for-linus] IO cost model based work-conserving porportional controller Jens Axboe
[not found] ` <20190829082248.6464-1-hdanton@sina.com>
2019-08-29 15:43 ` [PATCH 07/10] blk-mq: add optional request->alloc_time_ns Tejun Heo
[not found] ` <20190829133928.16192-1-hdanton@sina.com>
2019-08-29 15:46 ` [PATCH 08/10] blkcg: implement blk-iocost Tejun Heo
2019-08-29 15:54 ` [PATCHSET v3 block/for-linus] IO cost model based work-conserving porportional controller Paolo Valente
2019-08-29 15:56 ` Tejun Heo
-- strict thread matches above, loose matches on Subject: below --
2019-07-10 20:51 [PATCHSET v2 " Tejun Heo
2019-07-10 20:51 ` [PATCH 08/10] blkcg: implement blk-iocost Tejun Heo
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=20191101161506.GA28212@blackbody.suse.cz \
--to=mkoutny@suse.com \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=clm@fb.com \
--cc=dennisz@fb.com \
--cc=hannes@cmpxchg.org \
--cc=jbacik@fb.com \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=newella@fb.com \
--cc=paolo.valente@linaro.org \
--cc=riel@surriel.com \
--cc=tj@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).