On Mon, Jun 22, 2020 at 2:32 AM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > On Fri, Jun 19, 2020 at 08:50:36AM -0700, Matthew Wilcox wrote: > > > > This patch lifts the IOCB_CACHED idea expressed by Andreas to the VFS. > > The advantage of this patch is that we can avoid taking any filesystem > > lock, as long as the pages being accessed are in the cache (and we don't > > need to readahead any pages into the cache). We also avoid an indirect > > function call in these cases. > > What does this micro-optimisation actually gain us except for more > complexity in the IO path? > > i.e. if a filesystem lock has such massive overhead that it slows > down the cached readahead path in production workloads, then that's > something the filesystem needs to address, not unconditionally > bypass the filesystem before the IO gets anywhere near it. I'm fine with not moving that functionality into the VFS. The problem I have in gfs2 is that taking glocks is really expensive. Part of that overhead is accidental, but we definitely won't be able to fix it in the short term. So something like the IOCB_CACHED flag that prevents generic_file_read_iter from issuing readahead I/O would save the day for us. Does that idea stand a chance? We could theoretically also create a copy of generic_file_buffered_read in gfs2 and strip out the I/O parts, but that would be very messy. Thanks, Andreas
