linux-kernel - Re: [PATCH -tip] introduce sys_membarrier(): process-wide memory barrier (v9)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100303015326.GC28804@cloud>
Date:	Tue, 2 Mar 2010 17:53:27 -0800
From:	Josh Triplett <josh@...htriplett.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	mingo@...e.hu, KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Nicholas Miell <nmiell@...cast.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	laijs@...fujitsu.com, dipankar@...ibm.com,
	akpm@...ux-foundation.org, dvhltc@...ibm.com, niv@...ibm.com,
	tglx@...utronix.de, peterz@...radead.org, Valdis.Kletnieks@...edu,
	dhowells@...hat.com, linux-kernel@...r.kernel.org,
	Nick Piggin <npiggin@...e.de>,
	Chris Friesen <cfriesen@...tel.com>
Subject: Re: [PATCH -tip] introduce sys_membarrier(): process-wide memory
	barrier (v9)

On Tue, Mar 02, 2010 at 06:07:10PM -0500, Mathieu Desnoyers wrote:
> * Josh Triplett (josh@...htriplett.org) wrote:
> > On Thu, Feb 25, 2010 at 06:23:16PM -0500, Mathieu Desnoyers wrote:
> > > I am proposing this patch for the 2.6.34 merge window, as I think it is ready
> > > for inclusion.
> > > 
> > > Here is an implementation of a new system call, sys_membarrier(), which
> > > executes a memory barrier on all threads of the current process.
> > [...] 
> > 
> > > Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
> > > Acked-by: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
> > > Acked-by: Steven Rostedt <rostedt@...dmis.org>
> > > Acked-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> > > CC: Nicholas Miell <nmiell@...cast.net>
> > > CC: Linus Torvalds <torvalds@...ux-foundation.org>
> > > CC: mingo@...e.hu
> > > CC: laijs@...fujitsu.com
> > > CC: dipankar@...ibm.com
> > > CC: akpm@...ux-foundation.org
> > > CC: josh@...htriplett.org
> > 
> > Acked-by: Josh Triplett <josh@...htriplett.org>
> > 
> > I agree that v9 seems ready for inclusion.
> 
> Thanks!
> 
> > 
> > Out of curiosity, do you have any benchmarks for the case of not
> > detecting sys_membarrier dynamically?  Detecting it at library
> > initialization time, for instance, or even just compiling to assume its
> > presence?  I'd like to know how much that would improve the numbers.
> 
> Citing the patch changelog:
> 
> Results in liburcu:
> 
> Operations in 10s, 6 readers, 2 writers:
> 
> (what we previously had)
> memory barriers in reader: 973494744 reads, 892368 writes
> signal-based scheme:      6289946025 reads,   1251 writes
> 
> (what we have now, with dynamic sys_membarrier check, expedited scheme)
> memory barriers in reader: 907693804 reads, 817793 writes
> sys_membarrier scheme:    4316818891 reads, 503790 writes
> 
> So basically, yes, there is a significant overhead on the read-side if we
> compare the dynamic check (0.39 ns/read per reader) to the signal-based scheme
> (0.26 ns/read per reader) (which only needs the barrier()). On the update-side,
> we cannot care less though.

Just wanted to confirm that the signal results also hold for the
assume-sys_membarrier approach.

> > If significant, it might make sense to try to have a mechanism similar
> > to SMP alternatives, to have different code in either case.  dlopen,
> > function pointers, runtime code patching (nop out the rmb), or similar.
> 
> Yes, definitely. It could also be useful to switch between UP and SMP primitives
> dynamically when spawning the second thread in a process. We should be careful
> when sharing memory maps between processes though.

Might prove useful for some use cases, sure.  Not a high priority given
complexity:performance ratio though, I think.

- Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/