Re: [LSF/MM/BPF TOPIC] Filesystem inode reclaim

[Shakeel Butt <shakeel.butt@linux.dev>]

On Thu, Apr 16, 2026 at 12:06:59PM +0200, Jan Kara wrote:
> On Wed 15-04-26 10:45:11, Shakeel Butt wrote:
> > On Tue, Apr 14, 2026 at 11:15:48AM +0200, Jan Kara wrote:

[...]

> > One more question, I assume it is fs-dependent but is it possible to avoid
> > allocations (and thus reclaim) under fs-wide locks? One challenge/issue we at
> > Meta are seeing is (btrfs) lock holders getting stuck in reclaim causing
> > isolation issues.
> 
> I don't think it is practically feasible. Often before you acquire locks
> and start working, you don't know how much memory you'll need. For simple
> operations you can go with worst case estimates and preallocation before
> acquiring locks (like we do e.g. with radix tree manipulations) but for
> complex mutations of data structures involving journalling etc. it isn't
> really practical anymore - too much code to execute, too many possibilities
> to consider, too many interactions with other parts of the system.

Thanks for the explanation and yes I am on the same page that moving memory
allocations out of lock scope is not practical. (I am working on an idea to avoid
(specific) lock holders to not get stuck in reclaim but it is orthogonal to your
topic, so, don't want to divert the discussion. I will add more info in Boris's
proposal)