linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/5 v2] fs: Deferred inode reclaim
@ 2026-09-11  8:51 Jan Kara
  2026-09-11  8:51 ` [PATCH v2 1/5] writeback: Fix missed lazytime flush Jan Kara
                   ` (5 more replies)
  0 siblings, 6 replies; 8+ messages in thread
From: Jan Kara @ 2026-09-11  8:51 UTC (permalink / raw)
  To: linux-fsdevel
  Cc: linux-mm, Christian Brauner, Christoph Hellwig, Mikhail Rudenko,
	Jan Kara

Hello,

after a long pause here is a second 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).

This time I have fully tested the patch set. In particular it survives full
fstests run on ext4 both as is as well as 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 600k 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. btrfs is
hitting MM warnings in inode reclaim as well.

								Honza

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


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2026-09-11 15:05 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-11  8:51 [PATCH 0/5 v2] fs: Deferred inode reclaim Jan Kara
2026-09-11  8:51 ` [PATCH v2 1/5] writeback: Fix missed lazytime flush Jan Kara
2026-09-11  8:51 ` [PATCH v2 2/5] fs: Avoid inode dirtying on last iput Jan Kara
2026-09-11  8:51 ` [PATCH v2 3/5] fs: Basic infrastructure for offloading inode reclaim Jan Kara
2026-09-11  8:51 ` [PATCH v2 4/5] fs: Add throttling to deferred " Jan Kara
2026-09-11  8:51 ` [PATCH v2 5/5] ext4: Defer inode reclaim if it has preallocations Jan Kara
2026-09-11 14:55 ` [PATCH 0/5 v2] fs: Deferred inode reclaim Theodore Tso
2026-09-11 15:05   ` Darrick J. Wong

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).