On Wed, Feb 26, 2025 at 10:44:15AM -0500, Mike Snitzer wrote: > On Wed, Feb 26, 2025 at 06:58:11AM -0800, Christoph Hellwig wrote: > > On Mon, Feb 24, 2025 at 07:33:01PM -0500, Mike Snitzer wrote: > > > Add PF_KCOMPACTD flag and current_is_kcompactd() helper to check for > > > it so nfs_release_folio() can skip calling nfs_wb_folio() from > > > kcompactd. > > > > > > Otherwise NFS can deadlock waiting for kcompactd enduced writeback > > > which recurses back to NFS (which triggers writeback to NFSD via > > > NFS loopback mount on the same host, NFSD blocks waiting for XFS's > > > call to __filemap_get_folio): > > > > Having a flag for a specific kernel thread feels wrong. I'm not an > > expert in this area, but as fast as I can tell the problem is that > > kcompactd should be calling into ->release_folio without __GFP_IO > > set. > > We can easily remove PF_KCOMPACTD and current_is_kcompactd() if/when > more analysis and a cleaner fix emerges (from you, mm experts, etc). > I'm not saying you're wrong about GFP flags needing to be clamped by > kcompactd's call to ->release_folio, but it seems more finishing work > needed. > > As you can tell from my patch, we already have kswapd specialization > with PF_KSWAPD and current_is_kswapd(). A consumer of large folios > knowing that it being called as kcompactd is useful, hence my fix for > deadlock seen with NFS loopback mounts on memory constrained systems. Also, as followup to my fix: Trond and I have started exploring giving NFS the ability to do more meaningful work on behalf of kswapd and kcompactd from ->release_folio (rather than simply punt, by returning false, like your proposed GFP flag clamping would do), see: https://git.kernel.org/pub/scm/linux/kernel/git/snitzer/linux.git/commit/?h=kernel-6.12/nfs-next&id=b8fd0d3864e4bd43eaca1045002e89bede8fd91f (I'm still working on testing/refining this patch...)
