From: Ian Kent <raven@themaw.net>
To: Fox Chen <foxhlchen@gmail.com>
Cc: Tejun Heo <tj@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Rick Lindsley <ricklind@linux.vnet.ibm.com>,
Al Viro <viro@zeniv.linux.org.uk>,
David Howells <dhowells@redhat.com>,
Miklos Szeredi <miklos@szeredi.hu>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 0/6] kernfs: proposed locking and concurrency improvement
Date: Mon, 04 Jan 2021 08:42:37 +0800 [thread overview]
Message-ID: <04675888088a088146e3ca00ca53099c95fbbad7.camel@themaw.net> (raw)
In-Reply-To: <CAC2o3DJqK0ECrRnO0oArgHV=_S7o35UzfP4DSSXZLJmtLbvrKg@mail.gmail.com>
On Wed, 2020-12-23 at 15:30 +0800, Fox Chen wrote:
> Hi Ian,
>
> On Tue, Dec 22, 2020 at 3:47 PM Ian Kent <raven@themaw.net> wrote:
> > Here is what I currently have for the patch series we were
> > discussing
> > recently.
> >
> > I'm interested to see how this goes with the problem you are
> > seeing.
> >
> > The last patch in the series (the attributes update patch) has seen
> > no more than compile testing, I hope I haven't messed up on that.
>
> OK, I just ignored the last patch (kernfs: add a spinlock to kernfs
> iattrs for inode updates)
> because I can not boot the kernel after applying it.
Right, clearly I haven't got that last patch right yet.
It looks like the problem there is that the iattrs structure might
not be allocated at the time so clearly I can't just use the spin
lock inside.
It would be simple enough to resolve except for the need to set
the inode link count too.
Ian
>
> Applying the first five patches, my benchmark shows no improvement
> this time,
> one open+read+close cycle spends 500us. :(
>
> perf suggests that down_write in kernfs_iop_permission drags the most
> performance
> (full report see attachment) which makes sense to me, since
> down_write
> has no difference
> here compared to the mutex, they all allow only one thread running
> simultaneously.
>
> sigh... It's really hard to fix.
>
> |
> |--51.81%--inode_permission
> | |
> | --51.36%--kernfs_iop_permission
> | |
> | |--50.41%--down_write
> | | |
> | | --50.32%
> --rwsem_down_write_slowpath
> | | |
> | | --49.67%
> --rwsem_optimistic_spin
> | | |
> | | --49.31%
> --osq_lock
> | |
> | --0.74%--up_write
> | rwsem_wake.isra.0
> | |
> | --0.69%--wake_up_q
> | |
> | --0.62%
> --try_to_wake_up
> | |
> |
> --0.54%--_raw_spin_lock_irqsave
> |
> |
> |
> --0.52%--native_queued
> |
> --29.90%--walk_component
> |
> --29.72%--lookup_fast
> |
> --29.51%--kernfs_dop_revalidate
> |
> |--28.88%--down_read
> | |
> |
> --28.75%--rwsem_down_read_slowpath
> | |
> |
> --28.50%--rwsem_optimistic_spin
> |
> |
> |
> --28.38%--osq_lock
> |
> --0.59%--up_read
> rwsem_wake.isra.0
> |
> --0.54%--wake_up_q
> |
>
> --0.53%--try_to_wake_up
>
> > Please keep in mind that Greg's continued silence on the question
> > of whether the series might be re-considered indicates to me that
> > he has not changed his position on this.
>
> Since the problem doesn't break the system, it doesn't need immediate
> attention.
> So I bet it must be labeled with a low priority in Greg's to-do list.
> And it's merging
> window & holiday season. Let's just give him more time. :)
>
>
> > ---
> >
> > Ian Kent (6):
> > kernfs: move revalidate to be near lookup
> > kernfs: use VFS negative dentry caching
> > kernfs: use revision to identify directory node changes
> > kernfs: switch kernfs to use an rwsem
> > kernfs: stay in rcu-walk mode if possible
> > kernfs: add a spinlock to kernfs iattrs for inode updates
> >
> >
> > fs/kernfs/dir.c | 285 ++++++++++++++++++++++++++++---
> > ------------
> > fs/kernfs/file.c | 4 -
> > fs/kernfs/inode.c | 19 ++-
> > fs/kernfs/kernfs-internal.h | 30 ++++-
> > fs/kernfs/mount.c | 12 +-
> > fs/kernfs/symlink.c | 4 -
> > include/linux/kernfs.h | 5 +
> > 7 files changed, 238 insertions(+), 121 deletions(-)
> >
> > --
> > Ian
> >
>
> thanks,
> fox
next prev parent reply other threads:[~2021-01-04 0:44 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-22 7:47 [PATCH 0/6] kernfs: proposed locking and concurrency improvement Ian Kent
2020-12-22 7:47 ` [PATCH 1/6] kernfs: move revalidate to be near lookup Ian Kent
2020-12-22 7:47 ` [PATCH 2/6] kernfs: use VFS negative dentry caching Ian Kent
2020-12-22 7:47 ` [PATCH 3/6] kernfs: use revision to identify directory node changes Ian Kent
2020-12-22 7:48 ` [PATCH 4/6] kernfs: switch kernfs to use an rwsem Ian Kent
2020-12-22 7:48 ` [PATCH 5/6] kernfs: stay in rcu-walk mode if possible Ian Kent
2021-02-05 8:23 ` Fox Chen
2021-02-05 12:10 ` Ian Kent
2020-12-22 7:48 ` [PATCH 6/6] kernfs: add a spinlock to kernfs iattrs for inode updates Ian Kent
2020-12-24 6:23 ` [kernfs] ca0f27ecb7: BUG:kernel_NULL_pointer_dereference,address kernel test robot
2020-12-23 7:30 ` [PATCH 0/6] kernfs: proposed locking and concurrency improvement Fox Chen
2021-01-04 0:42 ` Ian Kent [this message]
2021-01-06 2:38 ` Fox Chen
2021-01-11 3:19 ` Ian Kent
2021-01-11 4:20 ` Ian Kent
2021-01-11 7:04 ` Fox Chen
2021-01-11 8:42 ` Ian Kent
2021-01-11 9:02 ` Fox Chen
2021-01-12 0:27 ` Ian Kent
2021-01-13 5:17 ` Ian Kent
2021-01-13 7:00 ` Fox Chen
2021-01-13 7:47 ` Ian Kent
2021-01-13 7:50 ` Ian Kent
2021-01-13 8:00 ` Fox Chen
2021-01-14 3:20 ` Fox Chen
2021-01-14 5:37 ` Ian Kent
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=04675888088a088146e3ca00ca53099c95fbbad7.camel@themaw.net \
--to=raven@themaw.net \
--cc=dhowells@redhat.com \
--cc=foxhlchen@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=ricklind@linux.vnet.ibm.com \
--cc=tj@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).