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]

Date:	Tue, 2 Mar 2010 18:07:10 -0500
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Josh Triplett <josh@...htriplett.org>
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)

* 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.

> 
> 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.

Thanks,

Mathieu

> 
> - Josh Triplett

-- 
Mathieu Desnoyers
Operating System Efficiency Consultant
EfficiOS Inc.
http://www.efficios.com
--
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/