On Mon, 31 Jan 2022, Matthew Wilcox wrote: > On Mon, Jan 31, 2022 at 03:03:53PM +1100, NeilBrown wrote: > > - .writepage to return AOP_WRITEPAGE_ACTIVATE if WB_SYNC_NONE > > and the flag is set. > > Is this actually useful? I ask because Dave Chinner believes > the call to ->writepage in vmscan to be essentially unused. He would be wrong ... unless "essentially" means "mostly" rather than "totally". swap-out to NFS results in that ->writepage call. Of course swap_writepage ignores sync_mode, so this might not be entirely relevant. But the main point of the patch is not to return AOP_WRITEPAGE_ACTIVATE to vmscan. It is to avoid writing at all when WB_SYNC_NONE and congested. e.g. for POSIX_FADV_DONTNEED It is also to allow the removal of congestion tracking with minimal changes to behaviour. If I end up changing some dead code into different dead code, I really don't care. I'm not here to clean up all dead code - only the dead code specifically related to congestion. NeilBrown > See commit 21b4ee7029c9, and I had a followup discussion with him > on IRC: > > <willy> dchinner: did you gather any stats on how often ->writepage was > being called by pageout() before "xfs: drop ->writepage completely" > was added? > <dchinner> willy: Never saw it on XFS in 3 years in my test environment... > <dchinner> I don't ever recall seeing the memory reclaim guards we put on > ->writepage in XFS ever firing - IIRC they'd been there for the best > part of a decade. > <willy> not so much the WARN_ON firing but the case where it actually calls > iomap_writepage > <dchinner> willy: I mean both - I was running with a local patch that warned > on writepage for a long time, regardless of where it was called from. > > I can believe things are different for a network filesystem, or maybe > XFS does background writeback better than other filesystems, but it > would be intriguing to be able to get rid of ->writepage altogether > (or at least from pageout(); migrate.c may be a thornier proposition). > >
