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