On Wed, Feb 28, 2024 at 07:37:58PM +0000, Matthew Wilcox wrote: > On Tue, Feb 27, 2024 at 09:19:47PM +0200, Amir Goldstein wrote: > > On Tue, Feb 27, 2024 at 8:56 PM Paul E. McKenney <paulmck@xxxxxxxxxx> wrote: > > > > > > Hello! > > > > > > Recent discussions [1] suggest that greater mutual understanding between > > > memory reclaim on the one hand and RCU on the other might be in order. > > > > > > One possibility would be an open discussion. If it would help, I would > > > be happy to describe how RCU reacts and responds to heavy load, along with > > > some ways that RCU's reactions and responses could be enhanced if needed. > > > > > > > Adding fsdevel as this should probably be a cross track session. > > Perhaps broaden this slightly. On the THP Cabal call we just had a > conversation about the requirements on filesystems in the writeback > path. We currently tell filesystem authors that the entire writeback > path must avoid allocating memory in order to prevent deadlock (or use > GFP_MEMALLOC). Is this appropriate? The reality is that filesystem developers have been ignoring that "mm rule" for a couple of decades. It was also discussed at LSFMM a decade ago (2014 IIRC) without resolution, so in the mean time we just took control of our own destiny.... > It's a lot of work to assure that > writing pagecache back will not allocate memory in, eg, the network stack, > the device driver, and any other layers the write must traverse. > > With the removal of ->writepage from vmscan, perhaps we can make > filesystem authors lives easier by relaxing this requirement as pagecache > should be cleaned long before we get to reclaiming it. .... by removing memory reclaim page cache writeback support from the filesystems entirely. IOWs, this rule hasn't been valid for a -long- time, so maybe it is time to remove it. :) Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
