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

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

On Thu, Feb 29, 2024 at 04:24:52AM +0000, Matthew Wilcox wrote:
> On Wed, Feb 28, 2024 at 11:17:33PM -0500, Kent Overstreet wrote:
> > On Wed, Feb 28, 2024 at 07:37:58PM +0000, Matthew Wilcox wrote:
> > > 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.
> > 
> > Why would you not simply mark the writeback path with
> > memalloc_nofs_save()?
> 
> It's not about preventing recursion, it's about guaranteeing forward
> progres.  If you can't allocate a bio, you can't clean memory.

Err, what? We have to be able to allocate bios in order to do writeback,
_period_. And not just bios, sometimes we have to bounce the entire IO.

I keep noticing the mm people developing weird, crazy ideas about it
being "unsafe" to allocate memory in various contexts. That's wrong;
attempting to allocate memory is always a _safe_ operation, provided you
tell the allocator what it's allowed to do. The allocation might fail,
and that's ok.

If code must succeed for the system to operate it must have fallbacks if
allocations fail, but we don't limit ourselves to those fallbacks
("avoid allocating memory") because then performance would be shit.

The PF_MEMALLOC suggestion is even weirder.

mm people are high on something...