Re: [LSF/MM/BPF Topic] Filesystem reclaim & memory allocation BOF

["Theodore Ts'o" <tytso@mit.edu>]

On Wed, Mar 26, 2025 at 03:25:07PM +0000, Matthew Wilcox wrote:
> 
> We've got three reports now (two are syzkaller kiddie stuff, but one's a
> real workload) of a warning in the page allocator from filesystems
> doing reclaim.  Essentially they're using GFP_NOFAIL from reclaim
> context.  This got me thinking about bs>PS and I realised that if we fix
> this, then we're going to end up trying to do high order GFP_NOFAIL allocations
> in the memory reclaim path, and that is really no bueno.
> 
> https://lore.kernel.org/linux-mm/20250326105914.3803197-1-matt@readmodwrite.com/
> 
> I'll prepare a better explainer of the problem in advance of this.

Thanks for proposing this as a last-minute LSF/MM topic!

I was looking at this myself, and was going to reply to the mail
thread above, but I'll do it here.

From my perspective, the problem is that as part of memory reclaim,
there is an attempt to shrink the inode cache, and there are cases
where an inode's refcount was elevated (for example, because it was
referenced by a dentry), and when the dentry gets flushed, now the
inode can get evicted.  But if the inode is one that has been deleted,
then at eviction time the file system will try to release the blocks
associated with the deleted-file.  This operation will require memory
allocation, potential I/O, and perhaps waiting for a journal
transaction to complete.

So basically, there are a class of inodes where if we are in reclaim,
we should probably skip trying to evict them because there are very
likely other inodes that will be more likely to result in memory
getting released expeditiously.  And if we take a look at
inode_lru_isolate(), there's logic there already about when inodes
should skipped getting evicted.  It's probably just a matter of adding
some additional coditions there.

This seems relatively straightforward; what am I missing?

> Required attendees: Ted, Luis, Chris, Josef, other people who've wrestled
> with this before.

Happy to be there!   :-)_

						- Ted