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@xxxxxxxxxxxxxx/). 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.
