On Mon, 2025-08-18 at 16:58 +0100, Matthew Wilcox wrote: > On Mon, Aug 18, 2025 at 08:56:31AM -0700, Trond Myklebust wrote: > > On Mon, 2025-08-18 at 16:21 +0100, Matthew Wilcox wrote: > > > I don't think this technique is "safe". By clearing the flag > > > early, > > > the page cache can't see that a folio that was created by > > > dropbehind > > > has now been reused and should have its dropbehind flag cleared. > > > So > > > we > > > might see pages dropped from the cache that really should not be. > > > > The only alternative would be to add back in a helper in > > mm/filemap.c > > that does the normal folio_end_writeback() routine, but ignores the > > dropbehind flag. (folio_end_writeback_ignore_dropbehind()?) > > Can you remind me why we clear the writeback flag as soon as the > WRITE > completes instead of leaving it set until the COMMIT completes? It's about reducing latency. An unstable WRITE is typically a quick operation because it only requires the server to cache the data. COMMIT requires persistence, and so it is typically slower. Furthermore, the intention of COMMIT is to also allow the batching of writeback on the server, so that disk wakeup and seeks are minimised. While that is probably much less of a concern with modern SSDs vs older hard drives, the NFS client design has to cater to both. So by clearing the writeback flag after the WRITE, we allow operations that want to further modify a specific folio to proceed without having to wait for persistence of the entire batch. More importantly, it also speeds up stat() calls, since we can retrieve the updated mtime+ctime values from the server as soon as the WRITEs are complete, without having to wait for COMMIT. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trondmy@xxxxxxxxxx, trond.myklebust@xxxxxxxxxxxxxxx
