Re: [PATCH 0/9] Improve I/O priority support

[Wang Jianchao <jianchao.wan9@gmail.com>]

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 ;)

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.
>