On Fri, May 10, 2024 at 12:14 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Fri, May 10, 2024 at 11:06:14AM +0800, Zhaoyang Huang wrote: > > On Thu, May 9, 2024 at 8:40 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > > > > > > + unsigned long budgt = inode->i_sb->s_bdev ? > > > > + blk_throttle_budgt(inode->i_sb->s_bdev) : 0; > > > > > > The readahead code is used for all file systems, you can't just call > > > into block layer code here. > > > > > ok. I would like to know any suggestions on introducing throttle > > budget control into readahead which actually works as a negative > > feedback path. IMO, negative feedback is a good methodology which has > > been used in scheduler(EAS) and thermal control(IPA) and > > memory(MGLRU). I would like to suggest to have a try on have it work > > cross the boundary of memory and block layer. > > > > vfs_read / page fault > > | > > readahead <---------| > > | | > > aops->readpages | > > | | > > block_layer------------ > > what you could do is have blk-throttle fail bios that are tagged as > readahead if we've hit the threshold? Actually, blk throttle will postpone the over-size bio's launch by adding it to the throttle group's private queue which this idea aims at. The delay here could be avoidable by some means to have the bio meet the max ability of the throttle blkcg. Furthermore, we may get a totally non over-sized readahead mechanism if we do this well.
