On Mon, 31 Jan 2022 at 05:47, NeilBrown <neilb@xxxxxxx> wrote: > > > +++ b/fs/fuse/file.c > > > @@ -958,6 +958,8 @@ static void fuse_readahead(struct readahead_control *rac) > > > > > > if (fuse_is_bad(inode)) > > > return; > > > + if (fc->num_background >= fc->congestion_threshold) > > > + return; > > > > This seems like a bad idea to me. If we don't even start reads on > > readahead pages, they'll get ->readpage called on them one at a time > > and the reading thread will block. It's going to lead to some nasty > > performance problems, exactly when you don't want them. Better to > > queue the reads internally and wait for congestion to ease before > > submitting the read. > > > > Isn't that exactly what happens now? page_cache_async_ra() sees that > inode_read_congested() returns true, so it doesn't start readahead. > ??? I agree. Fuse throttles async requests even before allocating them, which precludes placing them on any queue. I guess it was done to limit the amount of kernel memory pinned by a task (sync requests allow just one request per task). This has worked well, and I haven't heard complaints about performance loss due to readahead throttling. Thanks, Miklos
