From: Nathan Zimmer <nzimmer@sgi.com>
To: Jason Baron <jbaron@akamai.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"normalperson@yhbt.net" <normalperson@yhbt.net>,
"nzimmer@sgi.com" <nzimmer@sgi.com>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"nelhage@nelhage.com" <nelhage@nelhage.com>,
"davidel@xmailserver.org" <davidel@xmailserver.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 2/2 v2] epoll: Do not take global 'epmutex' for simple topologies
Date: Fri, 4 Oct 2013 12:54:00 -0500 [thread overview]
Message-ID: <20131004175359.GA153672@asylum.americas.sgi.com> (raw)
In-Reply-To: <524EDBBC.2060305@akamai.com>
On Fri, Oct 04, 2013 at 11:16:12AM -0400, Jason Baron wrote:
> On 10/03/2013 05:50 PM, Andrew Morton wrote:
> > On Tue, 1 Oct 2013 17:08:14 +0000 (GMT) Jason Baron <jbaron@akamai.com> wrote:
> >
> >> When calling EPOLL_CTL_ADD for an epoll file descriptor that is attached
> >> directly to a wakeup source, we do not need to take the global 'epmutex',
> >> unless the epoll file descriptor is nested. The purpose of taking
> >> the 'epmutex' on add is to prevent complex topologies such as loops and
> >> deep wakeup paths from forming in parallel through multiple EPOLL_CTL_ADD
> >> operations. However, for the simple case of an epoll file descriptor
> >> attached directly to a wakeup source (with no nesting), we do not need
> >> to hold the 'epmutex'.
> >>
> >> This patch along with 'epoll: optimize EPOLL_CTL_DEL using rcu' improves
> >> scalability on larger systems. Quoting Nathan Zimmer's mail on SPECjbb
> >> performance:
> >>
> >> "
> >> On the 16 socket run the performance went from 35k jOPS to 125k jOPS.
> >> In addition the benchmark when from scaling well on 10 sockets to scaling well
> >> on just over 40 sockets.
> >>
> >> ...
> >>
> >> Currently the benchmark stops scaling at around 40-44 sockets but it seems like
> >> I found a second unrelated bottleneck.
> >> "
> > I couldn't resist fiddling. Please review
> >
> > From: Andrew Morton <akpm@linux-foundation.org>
> > Subject: epoll-do-not-take-global-epmutex-for-simple-topologies-fix
> >
> > - use `bool' for boolean variables
> > - remove unneeded/undesirable cast of void*
> > - add missed ep_scan_ready_list() kerneldoc
>
> Hi Andrew,
>
> Looks good to me. Feel free to add:
>
> Reviewed-by: Jason Baron <jbaron@akamai.com>
>
> Thanks,
>
> -Jason
Just finished rerunning the benchmarks with this latest patchset, including the
fiddling, and it still looks great.
Thanks,
Nate
next prev parent reply other threads:[~2013-10-04 17:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-01 17:08 [PATCH 0/2 v2] epoll: reduce 'epmutex' lock contention Jason Baron
2013-10-01 17:08 ` [PATCH 1/2 v2] epoll: optimize EPOLL_CTL_DEL using rcu Jason Baron
2013-10-24 8:52 ` Paul E. McKenney
2013-10-24 14:56 ` Jason Baron
2013-10-01 17:08 ` [PATCH 2/2 v2] epoll: Do not take global 'epmutex' for simple topologies Jason Baron
2013-10-03 21:50 ` Andrew Morton
2013-10-04 15:16 ` Jason Baron
2013-10-04 17:54 ` Nathan Zimmer [this message]
2013-10-24 10:09 ` Paul E. McKenney
2013-10-24 16:00 ` Jason Baron
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=20131004175359.GA153672@asylum.americas.sgi.com \
--to=nzimmer@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=davidel@xmailserver.org \
--cc=jbaron@akamai.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nelhage@nelhage.com \
--cc=normalperson@yhbt.net \
--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
all inboxes | Powered by JetHome®