Re: [PATCH block-5.14] Revert "block/mq-deadline: Add cgroup support"

[Tejun Heo <tj@kernel.org>]

Hello,

On Thu, Aug 12, 2021 at 11:16:37AM -0700, Bart Van Assche wrote:
> Are you perhaps referring to the iocost and iolatency cgroup controllers? Is

and blk-throtl

> it ever useful to combine these controllers with the ioprio controller? The

So, I used controller as in cgroup IO controller, something which can
distribute IO resources hierarchically according to either weights or
limits. In that sense, there is no such thing as an ioprio controller.

> ioprio controller was introduced with the goal to provide the information to
> the storage controller about which I/O request to handle first. My

My experience has been that this isn't all that useful for generic IO
control scenarios involving cgroups. The configuration is too flexible
and granular to map to hardware priorities and there are way more
significant factors than how a controller manages its iternal ordering
on most commodity SSDs. For situations where such feature is useful,
cgroup might be able to help with tagging the associated priorities
but I don't think there's much beyond that and I have a hard time
seeing why the existing ioprio interface wouldn't be enough.

> understanding of the iocost and iolatency controllers is that these cgroup
> controllers decide in which order to process I/O requests. Neither
> controller has the last word over I/O order if the queue depth is larger
> than one, something that is essential to achieve reasonable performance.

Well, whoever owns the queue can control the latencies and it isn't
difficult to mess up while issuing one command at a time, so if the
strategy is stuffing device queue as much as possible and telling the
device what to do, the end result is gonna be pretty sad.

Thanks.

-- 
tejun