On Mon, 31 Jan 2022, Matthew Wilcox wrote: > On Mon, Jan 31, 2022 at 03:03:53PM +1100, NeilBrown wrote: > > diff --git a/fs/fuse/dax.c b/fs/fuse/dax.c > > index 182b24a14804..5f74e2585f50 100644 > > --- a/fs/fuse/dax.c > > +++ b/fs/fuse/dax.c > > @@ -781,6 +781,9 @@ static int fuse_dax_writepages(struct address_space *mapping, > > struct inode *inode = mapping->host; > > struct fuse_conn *fc = get_fuse_conn(inode); > > > > + if (wbc->sync_mode == WB_SYNC_NONE && > > + fc->num_background >= fc->congestion_threshold) > > + return 0; > > return dax_writeback_mapping_range(mapping, fc->dax->dev, wbc); > > This makes no sense. Doing writeback for DAX means flushing the > CPU cache (in a terribly inefficient way), but it's not going to > be doing anything in the background; it's a sync operation. Fair enough ... I was just being consistent. I didn't wonder if dax might be a bit special, but figured the change couldn't hurt. > > > +++ 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. ??? NeilBrown
