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
