On Mon, Jul 28, 2025 at 09:48:48AM -0400, Chuck Lever wrote: > On 7/28/25 9:44 AM, Mike Snitzer wrote: > > On Sun, Jul 27, 2025 at 11:39:18AM -0400, Chuck Lever wrote: > >> On 7/24/25 3:30 PM, Mike Snitzer wrote: > >>> Hi, > >>> > >>> Some workloads benefit from NFSD avoiding the page cache, particularly > >>> those with a working set that is significantly larger than available > >>> system memory. This patchset introduces _optional_ support to > >>> configure the use of O_DIRECT or DONTCACHE for NFSD's READ and WRITE > >>> support. The NFSD default to use page cache is left unchanged. > >>> > >>> The performance win associated with using NFSD DIRECT was previously > >>> summarized here: > >>> https://lore.kernel.org/linux-nfs/aEslwqa9iMeZjjlV@xxxxxxxxxx/ > >>> This picture offers a nice summary of performance gains: > >>> https://original.art/NFSD_direct_vs_buffered_IO.jpg > >>> > >>> Similarly, NFS and LOCALIO in particular also benefit from avoiding > >>> the page cache for workloads that have a working set that is > >>> significantly larger than available system memory. Enter: NFS DIRECT, > >>> which makes it possible to always enable LOCALIO to use O_DIRECT even > >>> if the IO is not DIO-aligned. > >>> > >>> For this v5 I've combined the NFSD and NFSD patchsets because the NFS > >>> changes do depend on the the NFSD changes. In addition, I think it > >>> makes sense to review/test these changes together. > >> > >> I'm ready to pull the six NFSD patches in this series into nfsd-testing. > >> IMO we want regression and performance testing of NFSD, outside of the > >> LOCALIO paths, before claiming merge readiness. > > > > Makes sense, the NFSD changes are independent. LOCALIO's access to > > the dio alignment attrs in nfsd_file is a convenience. > > As I was drifting off to sleep last night, my mind hallucinated the > idea that maybe all (three) caching modes should align the READ > payload. Would that make sense / simplify 06/13 ? As in nfsd_iter_read() no longer being passed @base? Sure it'd simplify things a bit, but not so much that it needs to be done as a prereq. Bigger bonus is that it reduces cause for needless inability to use DIO if/when configured to do so. So in that respect, definitely a good incremental improvement. Mike
