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

[Bart Van Assche <bvanassche@acm.org>]

On 5/27/21 10:58 AM, Adam Manzanares wrote:
> On Wed, 2021-05-26 at 18:01 -0700, 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.
> 
> When I worked in this area the goal was to control tail latencies for
> a prioritized app. Once the page cache is involved app control over
> IO is handed off suggesting that the priorities passed down to the
> device aren't as meaningful anymore.
> 
> Is passing the priority to the device making an impact to
> performance with your test case? If not, could BFQ be seen as a
> viable alternative.

Hi Adam,

As we all know complexity is the enemy of reliability. BFQ is
complicated so I am hesitant to use BFQ in a context where reliability
is important. Additionally, the BFQ scheduler uses heuristics to detect
the application type. As became clear recently, there heuristics can be
misled easily and fixing this is nontrivial (see also
https://lore.kernel.org/linux-block/20210521131034.GL18952@quack2.suse.cz/).
I want the application launcher to create one cgroup for foreground
applications and another cgroup for background applications. Configuring
different I/O priorities per cgroup is an easy and reliable approach to
communicate information about the application type and latency
expectations to the block layer.

Some database applications use buffered I/O and flush that data by
calling fsync(). We want to support such applications. So it seems like
we have a different opinion about whether or not an I/O priority should
be assigned to I/O that is the result of page cache writeback?

Thanks,

Bart.