From: Greg KH <gregkh@linuxfoundation.org>
To: Imran Khan <imran.f.khan@oracle.com>
Cc: tj@kernel.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org
Subject: Re: [RFC PATCH] kernfs: use kernfs_node specific mutex and spinlock.
Date: Fri, 24 Dec 2021 09:40:17 +0100 [thread overview]
Message-ID: <YcWHcZsBGFVDXYTY@kroah.com> (raw)
In-Reply-To: <1cbeb70b-6ae5-85fa-8f67-5da17974ed0b@oracle.com>
On Fri, Dec 24, 2021 at 09:52:51AM +1100, Imran Khan wrote:
> Hi everyone,
>
> On 16/12/21 2:06 am, Imran Khan wrote:
> > Right now a global mutex (kernfs_open_file_mutex) protects list of
> > kernfs_open_file instances corresponding to a sysfs attribute, so even
> > if different tasks are opening or closing different sysfs files they
> > can contend on osq_lock of this mutex. The contention is more apparent
> > in large scale systems with few hundred CPUs where most of the CPUs have
> > running tasks that are opening, accessing or closing sysfs files at any
> > point of time. Since each list of kernfs_open_file belongs to a
> > kernfs_open_node instance which in turn corresponds to one kernfs_node,
> > move global kernfs_open_file_mutex within kernfs_node so that it does
> > not block access to kernfs_open_file lists corresponding to other
> > kernfs_node.
> >
> > Also since kernfs_node->attr.open points to kernfs_open_node instance
> > corresponding to the kernfs_node, we can use a kernfs_node specific
> > spinlock in place of current global spinlock i.e kernfs_open_node_lock.
> > So make this spinlock local to kernfs_node instance as well.
> >
> > Signed-off-by: Imran Khan <imran.f.khan@oracle.com>
> > ---
> > I have kept this patch as RFC, as I am not sure if I have overlooked any
> > scenario(s) where these global locks are needed.
> >
>
> Could someone please provide some feedback about this change? Also if
> there is any issues in this change, can I make these locks per-fs as has
> been done in [1].
>
> [1] https://lore.kernel.org/lkml/YZvV0ESA+zHHqHBU@google.com/
Please test this using some tests to verify that sysfs is still working
properly and that this actually takes less time overall. In the
conversations about the last time kernfs was changed, there were lots of
discussions about proving that it actually mattered.
thanks,
greg k-h
next prev parent reply other threads:[~2021-12-24 8:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-15 15:06 [RFC PATCH] kernfs: use kernfs_node specific mutex and spinlock Imran Khan
2021-12-23 22:52 ` Imran Khan
2021-12-24 8:40 ` Greg KH [this message]
2022-01-03 9:07 ` Imran Khan
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=YcWHcZsBGFVDXYTY@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=imran.f.khan@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
/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.