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
