> Il giorno 28 mag 2021, alle ore 04:05, Wang Jianchao <jianchao.wan9@xxxxxxxxx> ha scritto: > > > > On 2021/5/28 2:40 AM, Bart Van Assche wrote: >> On 5/27/21 1:05 AM, Wang Jianchao wrote: >>> On 2021/5/27 2:25 PM, Wang Jianchao wrote: >>>> On 2021/5/27 9:01 AM, Bart Van Assche wrote: >>>>> A feature that is missing from the Linux kernel for storage devices that >>>>> support I/O priorities is to set the I/O priority in requests involving page >>>>> cache writeback. Since the identity of the process that triggers page cache >>>>> writeback is not known in the writeback code, the priority set by ioprio_set() >>>>> is ignored. However, an I/O cgroup is associated with writeback requests >>>>> by certain filesystems. Hence this patch series that implements the following >>>>> changes for the mq-deadline scheduler: >>>> >>>> How about implement this feature based on the rq-qos framework ? >>>> Maybe it is better to make mq-deadline a pure io-scheduler. >>> >>> In addition, it is more flexible to combine different io-scheduler and rq-qos policy >>> if we take io priority as a new policy ;) >> >> Hi Jianchao, >> >> That's an interesting question. I'm in favor of flexibility. However, >> I'm not sure whether it would be possible to combine an rq-qos policy >> that submits high priority requests first with an I/O scheduler that >> ignores I/O priorities. Since a typical I/O scheduler reorders requests, >> such a combination would lead to requests being submitted in the wrong >> order to storage devices. In other words, when using an I/O scheduler,> proper support for I/O priority in the I/O scheduler is essential. The > > Hi Bart, > > Does it really matter that issue IO request by the order of io priority ? > > Given a device with a 32 depth queue and doesn't support io priority, even if > we issue the request by the order of io priority, will the fw of device handle > them by the same order ? Or in the other word, we always issue 32 io requests > to device one time and then the fw of device decides how to handle them. > The order of dispatching request from queue may only work when the device's > queue is full and we have a deeper queue in io scheduler. And at this moment, > maybe the user needs to check why their application saturates the block device. > > As for the qos policy of io priority, it seems similar with wbt in which read, > sync write and background write have different priority. Since we always want > the io with higher priority to be served more by the device, adapting the depth > of queue of different io priority may work ;) > That's exactly what BFQ does, as this is the only option to truly control I/O in a device with internal queueing :) Thanks, Paolo > Best regards > Jianchao > >> BFQ I/O scheduler is still maturing. The purpose of the Kyber I/O >> scheduler is to control latency by reducing the queue depth without >> differentiating between requests of the same type. The mq-deadline >> scheduler is already being used in combination with storage devices that >> support I/O priorities in their controller. Hence the choice for the >> mq-deadline scheduler. >> >> Thanks, >> >> Bart.
