[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2025042121-cranial-famished-c249@gregkh>
Date: Mon, 21 Apr 2025 08:07:18 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Jinliang Zheng <alexjlzheng@...il.com>
Cc: alexjlzheng@...cent.com, linux-kernel@...r.kernel.org, tj@...nel.org
Subject: Re: [PATCH v2 0/2] kernfs: switch global locks to per-fs lock
On Sun, Apr 20, 2025 at 11:02:44PM +0800, Jinliang Zheng wrote:
> On Tue, 15 Apr 2025 23:36:57 +0800, Jinliang Zheng wrote:
> > From: Jinliang Zheng <alexjlzheng@...cent.com>
> >
> > The kernfs implementation has big lock granularity so every kernfs-based
> > (e.g., sysfs, cgroup) fs are able to compete the locks. This patchset
> > switches the global locks to per-fs locks.
> >
> > In fact, the implementation of global locks has not yet introduced
> > performance issues. But in the long run, more and more file systems will
> > be implemented based on the kernfs framework, so this optimization is
> > meaningful.
> >
> > There are three global locks now, kernfs_idr_lock, kernfs_rename_lock
> > and kernfs_pr_cont_lock. We only switch kernfs_idr_lock and
> > kernfs_rename_lock here, because kernfs_pr_cont_lock is on a cold path.
> >
> > Changelog:
> > v2: Only switch kernfs_idr_lock and kernfs_rename_lock to per-fs
> > v1: https://lore.kernel.org/all/20250411183109.6334-1-alexjlzheng@tencent.com/
> >
> > Jinliang Zheng (2):
> > kernfs: switch global kernfs_idr_lock to per-fs lock
> > kernfs: switch global kernfs_rename_lock to per-fs lock
> >
> > fs/kernfs/dir.c | 28 +++++++++++++++-------------
> > fs/kernfs/kernfs-internal.h | 16 ++++++++++++----
> > 2 files changed, 27 insertions(+), 17 deletions(-)
>
> Ding Dong ~
You ask this 5 days after submitting the last version, and that includes
3 of those days being a national holiday here (4 if you include today).
Please relax, I'll get to them "soon", only start to worry if it's been
more than 2 weeks.
In the meantime, to help out, please take the time to review other patch
submissions on the mailing lists. To not do so and just expect others
to only review yours is very unbalanced.
thanks,
greg k-h
Powered by blists - more mailing lists