From: josh@joshtriplett.org
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: linux-kernel@vger.kernel.org,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Steven Rostedt <rostedt@goodmis.org>,
Nicholas Miell <nmiell@comcast.net>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@redhat.com>,
Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
Lai Jiangshan <laijs@cn.fujitsu.com>,
Stephen Hemminger <stephen@networkplumber.org>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
David Howells <dhowells@redhat.com>
Subject: Re: [RFC PATCH v14] sys_membarrier(): system/process-wide memory barrier (x86)
Date: Wed, 18 Mar 2015 09:42:40 -0700 [thread overview]
Message-ID: <20150318164240.GA31251@cloud> (raw)
In-Reply-To: <1426695782-4742-1-git-send-email-mathieu.desnoyers@efficios.com>
On Wed, Mar 18, 2015 at 12:23:02PM -0400, Mathieu Desnoyers wrote:
> memory barriers in reader: 1701557485 reads, 3129842 writes
> signal-based scheme: 9825306874 reads, 5386 writes
> sys_membarrier: 7992076602 reads, 220 writes
>
> The dynamic sys_membarrier availability check adds some overhead to
> the read-side compared to the signal-based scheme, but besides that,
> with the expedited scheme, we can see that we are close to the read-side
> performance of the signal-based scheme. However, this non-expedited
> sys_membarrier implementation has a much slower grace period than signal
> and memory barrier schemes.
Doesn't the query flag allow you to find out in advance rather than
dynamically within the reader? What's the reader performance if you
hardcode availability of membarrier?
- Josh Triplett
next prev parent reply other threads:[~2015-03-18 16:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-18 16:23 [RFC PATCH v14] sys_membarrier(): system/process-wide memory barrier (x86) Mathieu Desnoyers
2015-03-18 16:42 ` josh [this message]
2015-03-18 16:52 ` Mathieu Desnoyers
2015-03-18 17:15 ` josh
2015-03-18 18:50 ` Mathieu Desnoyers
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=20150318164240.GA31251@cloud \
--to=josh@joshtriplett.org \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@redhat.com \
--cc=nmiell@comcast.net \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=stephen@networkplumber.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox