From: Jinliang Zheng <alexjlzheng@tencent.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(-)

-- 
2.49.0

On Tue, 15 Apr 2025 23:36:57 +0800, Jinliang Zheng wrote:
> From: Jinliang Zheng <alexjlzheng@tencent.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 ~

thanks,
Jinliang Zheng. :)

> 
> -- 
> 2.49.0

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@tencent.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