linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ian Kent <raven@themaw.net>
To: Fox Chen <foxhlchen@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tejun Heo <tj@kernel.org>, Al Viro <viro@zeniv.linux.org.uk>,
	Eric Sandeen <sandeen@sandeen.net>,
	Brice Goglin <brice.goglin@gmail.com>,
	Rick Lindsley <ricklind@linux.vnet.ibm.com>,
	David Howells <dhowells@redhat.com>,
	Miklos Szeredi <miklos@szeredi.hu>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 0/5] kernfs: proposed locking and concurrency improvement
Date: Thu, 13 May 2021 22:10:46 +0800	[thread overview]
Message-ID: <4eae44395ad321d05f47571b58fe3fe2413b6b36.camel@themaw.net> (raw)
In-Reply-To: <CAC2o3DJdwr0aqT6LwhuRj8kyXt6NAPex2nG5ToadUTJ3Jqr_4w@mail.gmail.com>

On Wed, 2021-05-12 at 16:54 +0800, Fox Chen wrote:
> On Wed, May 12, 2021 at 4:47 PM Fox Chen <foxhlchen@gmail.com> wrote:
> > 
> > Hi,
> > 
> > I ran it on my benchmark (
> > https://github.com/foxhlchen/sysfs_benchmark).
> > 
> > machine: aws c5 (Intel Xeon with 96 logical cores)
> > kernel: v5.12
> > benchmark: create 96 threads and bind them to each core then run
> > open+read+close on a sysfs file simultaneously for 1000 times.
> > result:
> > Without the patchset, an open+read+close operation takes 550-570
> > us,
> > perf shows significant time(>40%) spending on mutex_lock.
> > After applying it, it takes 410-440 us for that operation and perf
> > shows only ~4% time on mutex_lock.
> > 
> > It's weird, I don't see a huge performance boost compared to v2,
> > even
> 
> I meant I don't see a huge performance boost here and it's way worse
> than v2.
> IIRC, for v2 fastest one only takes 40us

Thanks Fox,

I'll have a look at those reports but this is puzzling.

Perhaps the added overhead of the check if an update is
needed is taking more than expected and more than just
taking the lock and being done with it. Then there's
the v2 series ... I'll see if I can dig out your reports
on those too.

> 
> 
> > though there is no mutex problem from the perf report.
> > I've put console outputs and perf reports on the attachment for
> > your reference.

Yep, thanks.
Ian


  reply	other threads:[~2021-05-13 14:11 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-12  0:38 [PATCH v4 0/5] kernfs: proposed locking and concurrency improvement Ian Kent
2021-05-12  0:38 ` [PATCH v4 1/5] kernfs: move revalidate to be near lookup Ian Kent
2021-05-12  0:38 ` [PATCH v4 2/5] kernfs: use VFS negative dentry caching Ian Kent
2021-05-12  0:39 ` [PATCH v4 3/5] kernfs: switch kernfs to use an rwsem Ian Kent
2021-05-12  0:39 ` [PATCH v4 4/5] kernfs: use i_lock to protect concurrent inode updates Ian Kent
2021-05-12  0:39 ` [PATCH v4 5/5] kernfs: add kernfs_need_inode_refresh() Ian Kent
2021-05-12  6:21 ` [PATCH v4 0/5] kernfs: proposed locking and concurrency improvement Greg Kroah-Hartman
2021-05-12  7:16   ` Fox Chen
2021-05-12  8:47     ` Fox Chen
2021-05-12  8:54       ` Fox Chen
2021-05-13 14:10         ` Ian Kent [this message]
2021-05-13 15:37           ` Fox Chen
2021-05-14  1:34             ` Ian Kent
2021-05-14  2:34               ` Fox Chen
2021-05-17  1:32                 ` Ian Kent
2021-05-18  8:26                   ` Fox Chen
2021-05-27  1:23                   ` Ian Kent
2021-05-27  6:50                     ` Greg Kroah-Hartman
2021-05-28  5:45                       ` Ian Kent
2021-05-13 13:50   ` Ian Kent
2021-05-13 15:19     ` Greg Kroah-Hartman
2021-05-14  1:02       ` 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=4eae44395ad321d05f47571b58fe3fe2413b6b36.camel@themaw.net \
    --to=raven@themaw.net \
    --cc=brice.goglin@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=foxhlchen@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=mtosatti@redhat.com \
    --cc=ricklind@linux.vnet.ibm.com \
    --cc=sandeen@sandeen.net \
    --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).