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

[Tejun Heo <tj@kernel.org>]

Hello,

On Thu, Aug 12, 2021 at 12:56:47PM -0600, Jens Axboe wrote:
> On the surface, #2 makes the most sense. But you'd then have to apply
> some scaling before it reaches the hardware side or is factored in by
> the underlying scheduler, or you could have a high priority from a
> cgroup that has small share of the total resources, yet ends up being
> regarded as more important than a lower priority request from a cgroup
> that has a much higher share of the total resources.

I don't think hardware side support is all that useful for mainstream
use cases. Whatever is controlling IO has to own the queue by being
the most throttling portion of the pipeline anyway and at least my
experience has been that what matters a lot more is the overall rate
of throttling rather than how specific IO is handled - ie. you can try
to feed one IO at a time to a SSD with the right priority marking but
it won't do much good if the sequence includes a lot of back-to-back
writes which can saturate some portion of the SSD in terms of
buffering and GC. Also, the configuration granularity is too coarse to
adapt to generic use cases and the history is pretty clear on optional
advanced features on mainstream storage devices.

> Hence not really sure it makes a lot of sense... We could probably come
> up with some heuristics that make some sense, but they'd still just be
> heuristics.

Yeah, I have a hard time imagining a sane and logical mapping between
cgroup IO control and hardware prioritization features. For use cases
and hardware configuration which can benefit from prioritization on
the hardware side, I think the right solution is doing it outside the
cgroup framework, or at least the usual IO controllers.

Thanks.

-- 
tejun