On Thu 05-01-23 17:18:54, Michal Koutný wrote: > Hello Jinke. > > On Mon, Dec 26, 2022 at 09:05:05PM +0800, Jinke Han <hanjinke.666@xxxxxxxxxxxxx> wrote: > > In our test, fio writes a 100g file in sequential 4k blocksize in > > a container with low bps limit configured (wbps=10M). > > [...] > > At the same time, the operation of saving a small file by vim will be > > blocked amolst 140s. > > Could you please elaborate why is this specific to blk-throtl? > > I guess similar problem would arise for devices that are "naturally" > slow. > Then: > a) it must have been solved elsewhere in the block layer (but it's > broken), > b) it should be solved generically in the block layer (thus this is only > a partial solution). Generally, problems are this are taken care of by IO schedulers. E.g. BFQ has quite a lot of logic exactly to reduce problems like this. Sync and async queues are one part of this logic inside BFQ (but there's more). But given current architecture of the block layer IO schedulers are below throttling frameworks such as blk-throtl so they have no chance of influencing problems like this. So we are bound to reinvent the scheduling logic IO schedulers are already doing. That being said I don't have a good solution for this or architecture suggestion. Because implementing various throttling frameworks within IO schedulers is cumbersome (complex interactions) and generally the perfomance is too slow for some usecases. We've been there (that's why there's cgroup support in BFQ) and really the current architecture is much easier to reason about. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
