From: Tejun Heo <tj@kernel.org>
To: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Christian Brauner <christian@brauner.io>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Meta kernel team <kernel-team@meta.com>,
linux-fsdevel@vger.kernel.org, driver-core@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kernfs: allocate the open node outside the open file mutex
Date: Thu, 10 Sep 2026 11:12:46 -1000 [thread overview]
Message-ID: <aqMdToJ99NeqC1zj@slm.duckdns.org> (raw)
In-Reply-To: <20260910045433.489413-1-shakeel.butt@linux.dev>
On Wed, Sep 09, 2026 at 09:54:33PM -0700, Shakeel Butt wrote:
> kernfs_get_open_node() allocates the kernfs_open_node while holding one
> of the hashed kernfs_open_file mutexes, so opening a file nobody has open
> yet can enter reclaim with that mutex held. The mutex is shared by every
> node that hashes to it, so unrelated opens, closes and xattr updates in
> the same bucket wait.
>
> It is the most contended lock in kernfs on our fleet: 2.19M waiters over
> 29 days, more than two hundred times the waiters on kernfs_rwsem, and the
> highest median hold of any kernfs lock at 77ms. Most of it is monitoring
> daemons opening cgroup control files, and the open node is freed once the
> last descriptor closes, so an open-read-close loop allocates every time.
>
> Look at kn->attr.open before taking the mutex, and allocate then if
> nothing has the file open. Should the peek be wrong, which needs the
> last descriptor to close inside the window, fall back to allocating under
> the mutex as before.
>
> Eight tasks opening and closing four cgroup files 20000 times each, with
> lock_stat on the hashed mutex:
>
> contentions hold total hold avg
> before 198 4.19 s 8.67 us
> after 119 2.31 s 4.78 us
>
> and the same number of acquisitions either way.
>
> This does not empty the bucket. kernfs_fop_release() and
> kernfs_xattr_set() still sleep under the same mutex. It stops opens
> doing it.
>
> Assisted-by: LLM
> Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev>
Acked-by: Tejun Heo <tj@kernel.org>
Thanks.
--
tejun
prev parent reply other threads:[~2026-09-10 21:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 4:54 [PATCH] kernfs: allocate the open node outside the open file mutex Shakeel Butt
2026-09-10 21:12 ` Tejun Heo [this message]
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=aqMdToJ99NeqC1zj@slm.duckdns.org \
--to=tj@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=christian@brauner.io \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-team@meta.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shakeel.butt@linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.