From: sashiko-bot@kernel.org
To: JonasZhou-oc <jonaszhou-oc@zhaoxin.com>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH v3] ext4: move orphan tracking away from journal state
Date: Fri, 11 Sep 2026 03:44:12 +0000 [thread overview]
Message-ID: <20260911034412.7B66B1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <67ae57ef2ee3ac27ab844c22594351c83142d86f.1789097450.git.jonaszhou@zhaoxin.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Moving `s_orphan_lock` introduces new false sharing with the highly-contended `s_es_lock`.
--
commit 269f37a627203c8f7267166bbe89e9f2dfb71db7
Author: Jonas Zhou <jonaszhou@zhaoxin.com>
ext4: move orphan tracking away from journal state
Move s_orphan_lock, s_orphan and s_orphan_info together below
s_journal_triggers to separate orphan-list writes from journal
and flag readers.
Link: https://lore.kernel.org/all/575wyoks3ldokhrg6v43rxwsegaecod4bgrpbii6jeczy7czbi@a3yq26u52orp/
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index 724a27e8be613..1669109149731 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
[ ... ]
> @@ -1786,6 +1782,12 @@ struct ext4_sb_info {
> /* Journal triggers for checksum computation */
> struct ext4_journal_trigger s_journal_triggers[EXT4_JOURNAL_TRIGGER_COUNT];
>
> + /* Orphan inode tracking */
> + struct mutex s_orphan_lock; /* Protects on disk list changes */
[Severity: Medium]
Does moving s_orphan_lock here introduce false sharing with s_es_lock?
On 64-bit architectures, s_es_lock (4 bytes), pointer alignment padding
(4 bytes), s_journal_triggers (24 bytes for a single 1-element array), and
s_orphan_lock (32 bytes) perfectly sum to 64 bytes. This places s_orphan_lock
exactly in the same 64-byte cacheline as s_es_lock.
This can cause cacheline bouncing during concurrent operations modifying extent
status trees and orphan lists, such as parallel unlinks.
> + struct list_head s_orphan; /* List of orphaned inodes in on disk
> + list */
> + struct ext4_orphan_info s_orphan_info;
> +
> /* Ratelimit ext4 messages. */
> struct ratelimit_state s_err_ratelimit_state;
> struct ratelimit_state s_warning_ratelimit_state;
--
Sashiko AI review · https://sashiko.dev/#/patchset/67ae57ef2ee3ac27ab844c22594351c83142d86f.1789097450.git.jonaszhou@zhaoxin.com?part=1
next prev parent reply other threads:[~2026-09-11 3:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 2:18 [PATCH] ext4: isolate s_orphan_lock from read-mostly fields JonasZhou-oc
2026-09-03 2:23 ` sashiko-bot
2026-09-03 10:25 ` Jan Kara
2026-09-07 10:55 ` JonasZhou-oc
2026-09-07 11:12 ` [PATCH v2] ext4: move journal state away from orphan list updates JonasZhou-oc
2026-09-07 11:23 ` sashiko-bot
2026-09-08 11:14 ` Jan Kara
2026-09-11 3:31 ` [PATCH v3] ext4: move orphan tracking away from journal state JonasZhou-oc
2026-09-11 3:44 ` sashiko-bot [this message]
2026-09-11 9:40 ` 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=20260911034412.7B66B1F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=jonaszhou-oc@zhaoxin.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tytso@mit.edu \
/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