Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Reclamation interactions with RCU

[Kent Overstreet <kent.overstreet@linux.dev>]

On Thu, Feb 29, 2024 at 12:29:35PM +1100, Dave Chinner wrote:
> 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@kernel.org> 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. :)

It's _never_ been valid, the entire IO stack allocates memory.

This is what GFP_NOIO/GFP_NOFS is for, and additionaly mempools/biosets.
If mm can't satisfy the allocation, they should fail it, and then the IO
path will have fallbacks (but they wil be slow, i.e. iodepth will be
greatly limited).