From: Jan Kara <jack@suse.cz>
To: <linux-fsdevel@vger.kernel.org>
Cc: <linux-mm@kvack.org>, Christian Brauner <brauner@kernel.org>,
Christoph Hellwig <hch@infradead.org>,
Mikhail Rudenko <xyzzy@yandex-team.ru>,
Andreas Gruenbacher <agruenba@redhat.com>,
Jan Kara <jack@suse.cz>
Subject: [PATCH 0/7 v3] fs: Deferred inode reclaim
Date: Mon, 12 Oct 2026 10:23:38 +0200 [thread overview]
Message-ID: <20261009133253.20102-1-jack@suse.cz> (raw)
Hello,
here is the third revision of my patches implementing deferred inode reclaim to
deal with MM warnings due to GFP_NOFAIL allocations from reclaim paths. This
happens because to reclaim some inodes, filesystems have to do IO including
complex operations using journalling and forward progress of these depends on
successful memory allocations (which is impossible to guarantee from reclaim
context).
Since the last revision the most notable changes include addition of automatic
deferal of inode eviction from iput() when inode link-count is 0 and we are in
reclaim (PF_MEMALLOC flag set). This path gets triggered e.g. by overlayfs
whose inodes hold dentry references on upper filesystem and thus slab reclaim
of overlayfs inodes can trigger the last dput() (and thus iput()) of already
unlinked files. Since inode deletion is practically guaranteed to require IO
(and thus possibly e.g. loading allocation information into memory) I've
decided to unconditionally defer reclaim in this case instead of marking inodes
in each filesystem.
Another bigger change in this series is that we now protect deferred inode
reclaim from filesystem freezing. Otherwise inode eviction could block the
reclaim worker on frozen filesystem which could stall deferred inode reclaim on
the whole system. Deferred reclaim workers now skip reclaiming inodes on frozen
filesystem and we block filesystem freezing while the worker is evicting
current batch of its inodes.
The last bigger change is that mark_inode_reclaim_deferred() does not block
when the queue of deferred inodes grows over limit anymore. Instead it queues
task work to delay the task appropriately when returning to userspace. This
solves possible lockups when tasks would get throttled when calling
mark_inode_reclaim_deferred() with some locks or transaction started.
The patches have survived full fstests run on ext4 when marking all loaded ext4
inodes for deferred reclaim to stress the deferred reclaim paths. I have also
tested (when marking all inodes for deferred reclaim) the patches by creating a
memcg with 128m memory limit and then scanning from 10 processes 1m inodes in
total which heavily exercises deferred inode reclaim paths. This also verified
efficiency of throttling of marking of inodes for deferred reclaim. Basically
we cannot guarantee any particular limit on the number of inodes queued for
deferred reclaim as that is bound only by their number in memory and memory
pressure. But as the number of queued inodes grows, the tasks creating them get
slowed down so eventually some equilibrium is hit. In my VM this was at ~10k
inodes (only slightly above the 8k limit when throttling kicks in) but this all
very much depends on the reclaim pressure, speed of deferred reclaim etc. so I
don't think this is some representative number.
The first patch is a pure fix for a problem I've hit when running fstests. The
second patch deals with lazy timestamp updates which I've decided to handle
better directly inside the writeback infrastructure instead of deferring
reclaim. The remaining patches implement the inode reclaim deferal. Ext4 use of
deferred inode reclaim is there mostly as a demonstration. Other filesystems
need to determine which inodes need deferred reclaim and mark them as such
which generally requires good internal knowledge of the filesystem. I'm hoping
that once the infrastructure is there, fs developers prompted by MM warnings
will start using it :). I know for a fact that besides ext4 e.g. gfs2 wants
to use this infrastructure.
Honza
Changes since v2:
* Some cleanups and simplifications from Andreas Grunbacher
* Fixed couple of bugs pointed out by Sashiko
* Added support for auto-deferring eviction from iput() when inode has 0 link
count and we are in reclaim path
* Added protection of deferred reclaim from filesystem freezing
* Throttling now doesn't happen directly in mark_inode_reclaim_deferred() but
on exit to userspace
Changes since v1:
* Multiple workers to reclaim deferred inodes, related to that I've
moved lists of deferred inodes from per-sb to global ones
* Added missed lazytime sync fix
Previous versions:
Link: http://lore.kernel.org/r/20260429174850.18223-1-jack@suse.cz # v1
Link: http://lore.kernel.org/r/20260911081309.14137-1-jack@suse.cz # v2
next reply other threads:[~2026-10-12 8:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 8:23 Jan Kara [this message]
2026-10-12 8:23 ` [PATCH 1/7] writeback: Fix missed lazytime flush Jan Kara
2026-10-12 8:23 ` [PATCH 2/7] fs: Avoid inode dirtying on last iput Jan Kara
2026-10-12 8:23 ` [PATCH 3/7] fs: Basic infrastructure for offloading inode reclaim Jan Kara
2026-10-12 8:23 ` [PATCH 4/7] fs: Defer reclaim of unlinked inodes Jan Kara
2026-10-12 8:23 ` [PATCH 5/7] fs: Add throttling to deferred inode reclaim Jan Kara
2026-10-12 8:23 ` [PATCH 6/7] fs: Protect deferred inode reclaim from freezing Jan Kara
2026-10-12 8:23 ` [PATCH 7/7] ext4: Defer inode reclaim if it has preallocations Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261009133253.20102-1-jack@suse.cz \
--to=jack@suse.cz \
--cc=agruenba@redhat.com \
--cc=brauner@kernel.org \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=xyzzy@yandex-team.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox