On Thu, 2021-05-27 at 11:53 -0700, Bart Van Assche wrote: > 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. Ok, now I know why you are staying away from BFQ. Thanks for sharing this information. > > 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? Not necessarily, I am just a bit cautious because in my experience prioritized I/O has benefits as well as limitations. You just have to make sure that the page cache writeback does not push the hardware to a point where the I/O prioritization is no longer beneficial. > Thanks, > > Bart. >
