From: Jan Kara <jack@suse.cz>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org,
Christian Brauner <brauner@kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-ext4@vger.kernel.org, Ted Tso <tytso@mit.edu>,
"Tigran A. Aivazian" <aivazian.tigran@gmail.com>,
David Sterba <dsterba@suse.com>,
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
David Hildenbrand <david@kernel.org>,
linux-mm@kvack.org, linux-aio@kvack.org,
Benjamin LaHaise <bcrl@kvack.org>
Subject: Re: [PATCH 20/41] fs: Ignore inode metadata buffers in inode_lru_isolate()
Date: Tue, 24 Mar 2026 13:51:18 +0100 [thread overview]
Message-ID: <flb3si2jxjg4gy7beqxr3zt3tvq74msftee5ewmwgpd77vqj5r@h5rqgjuws3zr> (raw)
In-Reply-To: <acIkOmat4Y_M2SUC@infradead.org>
On Mon 23-03-26 22:42:18, Christoph Hellwig wrote:
> On Fri, Mar 20, 2026 at 02:41:15PM +0100, Jan Kara wrote:
> > There are only a few filesystems that use generic tracking of inode
> > metadata buffer heads. As such it is mostly pointless to verify such
> > attached buffer heads during inode reclaim. Drop the handling from
> > inode_lru_isolate().
>
> But the code isn't just verifying (which to me implies debug code),
> but doing actual work to remove the buffers. This does look like a
> behavior change to me, buf it is not due to previous patches or
> because it was dead code, it would help greatly to explain that here.
Right, I've rewritten the changelog to explain things better:
There are only a few filesystems that use generic tracking of inode
metadata buffer heads. As such the logic to reclaim tracked metadata
buffer heads in inode_lru_isolate() doesn't bring a benefit big enough
to justify intertwining of inode reclaim and metadata buffer head
tracking. Just treat tracked metadata buffer heads as any other metadata
filesystem has to properly clean up on inode eviction and stop handling
it in inode_lru_isolate(). As a result filesystems using generic
tracking of metadata buffer heads may now see dirty metadata buffers in
their .evict methods more often which can slow down inode reclaim but
given these filesystems aren't used in performance demanding setups we
should be fine.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2026-03-24 12:51 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 13:40 [PATCH v2 0/41] fs: Move metadata bh tracking from address_space Jan Kara
2026-03-20 13:40 ` [PATCH 01/41] ext4: Use inode_has_buffers() Jan Kara
2026-03-20 13:40 ` [PATCH 02/41] gfs2: Don't zero i_private_data Jan Kara
2026-03-20 13:40 ` [PATCH 03/41] ntfs3: Drop pointless sync_mapping_buffers() and invalidate_inode_buffers() calls Jan Kara
2026-03-20 13:40 ` [PATCH 04/41] ocfs2: Drop pointless sync_mapping_buffers() calls Jan Kara
2026-03-23 10:46 ` Joseph Qi
2026-03-20 13:41 ` [PATCH 05/41] bdev: Drop pointless invalidate_inode_buffers() call Jan Kara
2026-03-20 13:41 ` [PATCH 06/41] ufs: Drop pointless invalidate_mapping_buffers() call Jan Kara
2026-03-20 13:41 ` [PATCH 07/41] exfat: Drop pointless invalidate_inode_buffers() call Jan Kara
2026-03-20 13:41 ` [PATCH 08/41] udf: Switch to generic_buffers_fsync() Jan Kara
2026-03-24 5:38 ` Christoph Hellwig
2026-03-24 12:24 ` Jan Kara
2026-03-20 13:41 ` [PATCH 09/41] minix: " Jan Kara
2026-03-20 13:41 ` [PATCH 10/41] bfs: " Jan Kara
2026-03-20 13:41 ` [PATCH 11/41] fat: Switch to generic_buffers_fsync_noflush() Jan Kara
2026-03-20 13:41 ` [PATCH 12/41] fs: Drop sync_mapping_buffers() from __generic_file_fsync() Jan Kara
2026-03-24 5:40 ` Christoph Hellwig
2026-03-24 12:34 ` Jan Kara
2026-03-24 13:17 ` Christoph Hellwig
2026-03-24 13:36 ` Jan Kara
2026-03-24 15:54 ` Christoph Hellwig
2026-03-25 19:01 ` Jan Kara
2026-03-20 13:41 ` [PATCH 13/41] fat: Sync and invalidate metadata buffers from fat_evict_inode() Jan Kara
2026-03-20 13:41 ` [PATCH 14/41] udf: Sync and invalidate metadata buffers from udf_evict_inode() Jan Kara
2026-03-20 13:41 ` [PATCH 15/41] minix: Sync and invalidate metadata buffers from minix_evict_inode() Jan Kara
2026-03-20 13:41 ` [PATCH 16/41] ext2: Sync and invalidate metadata buffers from ext2_evict_inode() Jan Kara
2026-03-20 13:41 ` [PATCH 17/41] ext4: Sync and invalidate metadata buffers from ext4_evict_inode() Jan Kara
2026-03-20 13:41 ` [PATCH 18/41] bfs: Sync and invalidate metadata buffers from bfs_evict_inode() Jan Kara
2026-03-20 13:41 ` [PATCH 19/41] affs: Sync and invalidate metadata buffers from affs_evict_inode() Jan Kara
2026-03-20 13:41 ` [PATCH 20/41] fs: Ignore inode metadata buffers in inode_lru_isolate() Jan Kara
2026-03-24 5:42 ` Christoph Hellwig
2026-03-24 12:51 ` Jan Kara [this message]
2026-03-20 13:41 ` [PATCH 21/41] fs: Stop using i_private_data for metadata bh tracking Jan Kara
2026-03-24 5:42 ` Christoph Hellwig
2026-03-20 13:41 ` [PATCH 22/41] hugetlbfs: Stop using i_private_data Jan Kara
2026-03-24 5:42 ` Christoph Hellwig
2026-03-20 13:41 ` [PATCH 23/41] aio: Stop using i_private_data and i_private_lock Jan Kara
2026-03-24 5:43 ` Christoph Hellwig
2026-03-20 13:41 ` [PATCH 24/41] fs: Remove i_private_data Jan Kara
2026-03-24 5:43 ` Christoph Hellwig
2026-03-20 13:41 ` [PATCH 25/41] kvm: Use private inode list instead of i_private_list Jan Kara
2026-03-24 5:44 ` Christoph Hellwig
2026-03-20 13:41 ` [PATCH 26/41] fs: Drop osync_buffers_list() Jan Kara
2026-03-24 5:44 ` Christoph Hellwig
2026-03-20 13:41 ` [PATCH 27/41] fs: Fold fsync_buffers_list() into sync_mapping_buffers() Jan Kara
2026-03-24 5:44 ` Christoph Hellwig
2026-03-20 13:41 ` [PATCH 28/41] fs: Move metadata bhs tracking to a separate struct Jan Kara
2026-03-24 5:47 ` Christoph Hellwig
2026-03-20 13:41 ` [PATCH 29/41] fs: Make bhs point to mapping_metadata_bhs Jan Kara
2026-03-24 5:48 ` Christoph Hellwig
2026-03-20 13:41 ` [PATCH 30/41] fs: Switch inode_has_buffers() to take mapping_metadata_bhs Jan Kara
2026-03-24 5:48 ` Christoph Hellwig
2026-03-20 13:41 ` [PATCH 31/41] fs: Provide functions for handling mapping_metadata_bhs directly Jan Kara
2026-03-24 5:51 ` Christoph Hellwig
2026-03-25 19:00 ` Jan Kara
2026-03-20 13:41 ` [PATCH 32/41] ext2: Track metadata bhs in fs-private inode part Jan Kara
2026-03-20 13:41 ` [PATCH 33/41] affs: " Jan Kara
2026-03-20 13:41 ` [PATCH 34/41] bfs: " Jan Kara
2026-03-20 13:41 ` [PATCH 35/41] fat: " Jan Kara
2026-03-20 13:41 ` [PATCH 36/41] udf: " Jan Kara
2026-03-20 13:41 ` [PATCH 37/41] minix: " Jan Kara
2026-03-20 13:41 ` [PATCH 38/41] ext4: " Jan Kara
2026-03-20 13:41 ` [PATCH 39/41] fs: Drop mapping_metadata_bhs from address space Jan Kara
2026-03-20 13:41 ` [PATCH 40/41] fs: Drop i_private_list from address_space Jan Kara
2026-03-20 13:41 ` [PATCH 41/41] fs: Unify generic_file_fsync() with mmb methods Jan Kara
2026-03-24 5:56 ` Christoph Hellwig
2026-03-24 13:28 ` Jan Kara
2026-03-23 10:20 ` [PATCH v2 0/41] fs: Move metadata bh tracking from address_space Christian Brauner
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=flb3si2jxjg4gy7beqxr3zt3tvq74msftee5ewmwgpd77vqj5r@h5rqgjuws3zr \
--to=jack@suse.cz \
--cc=aivazian.tigran@gmail.com \
--cc=bcrl@kvack.org \
--cc=brauner@kernel.org \
--cc=david@kernel.org \
--cc=dsterba@suse.com \
--cc=hch@infradead.org \
--cc=hirofumi@mail.parknet.co.jp \
--cc=linux-aio@kvack.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/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