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

[Matthew Wilcox <willy@infradead.org>]

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?  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.

I don't think there's anything to be done about swapping anon memory.
We probably don't want to proactively write anon memory to swap, so by
the time we're in ->swap_rw we really are low on memory.