This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/13976] New: Possible enhancement in NPTL spin-lock code on x86 architectures: pause
- From: "tschwinge at sourceware dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Thu, 12 Apr 2012 20:44:32 +0000
- Subject: [Bug nptl/13976] New: Possible enhancement in NPTL spin-lock code on x86 architectures: pause
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=13976
Bug #: 13976
Summary: Possible enhancement in NPTL spin-lock code on x86
architectures: pause
Product: glibc
Version: unspecified
Status: NEW
Severity: enhancement
Priority: P2
Component: nptl
AssignedTo: unassigned@sourceware.org
ReportedBy: tschwinge@sourceware.org
CC: drepper.fsp@gmail.com
Classification: Unclassified
It may be possible to optimize NPTL's spin-locking code by using the
pause instruction on x86 architectures.
IRC, freenode, #glibc, 2012-04-05:
<janimo> hi, I saw code (in mongodb fwiw) that inserts asm volatile
("pause") in a loop that uses pthread_spin_trylock() as recommended by
some PIV Intel manuals
<janimo> is that a usage that was considered in glibc, is it safe/sane for
most such busy loops?
<janimo>
https://github.com/mongodb/mongo/blob/master/src/mongo/util/concurrency/spin_lock.cpp#L54
<pasky> interesting, i've never seen that
<tschwinge> janimo: First, I'm not an expert on this topic. I just had a
look at NPTL, and it does not make use of pause. Please send your
proposal, along with some further explanation and rationale to
libc-alpha.
<janimo> tschwinge, I also checked the sources and saw tha ia64 only uses
asm("pause")
<pasky> hmm it seems legitimate
<tschwinge> Aha, the tree I lokked at doesn't contain ia64 anymore. ;-)
<tschwinge> pasky: Yes, I think so too.
<janimo> ans I was mostly asking a question rather than proposing
something, gien that I assume Intel's PIV is old news for eglibc
deelopers and the thought may already hae crossed their minds years ago
:)
<pasky> usually, sched_yield() seems more sane
<tschwinge> And surely some folks have been doing performance measurements,
etc.
<pasky> but if you have a specific case where you have a guarantee that the
other thread is on a different core etc., pause may be more effective
<pasky> (or when you cannot afford the sched_yield() syscall overhead)
<tschwinge> pasky: WOuld you really be using such a spinlock in cases where
you'd be willing to do a syscall?
<janimo> ok, could be it is application/load specific and so better left to
app developers...
<pasky> tschwinge: you are right
<janimo> I had done no benchmarks myself, just hit this snippet of
non-portable code in mongodb and was wondering how useful it is generally
* pasky shuffles away for some coffee
<pasky>
http://people.apache.org/~dongsheng/git.cgi?p=libpthread;a=commitdiff;h=22f596c6d1f355aaf582e10b1bb1256056cafaf4
<pasky> seems like apache's libpthread also uses pause
<janimo> pasky, tschwinge btw they use sched_yield to a few lines later
<janimo> the mongo code
<pasky> I wouldn't trust NTPL to be necessarily super-optimized so maybe it
really is good idea, but good benchmarking would be required to adopt
this i think
<janimo> pasky, the apache code has pause on an #if 0 branch though
<pasky> well so what's cpu_relax(); ?
<janimo> cpu_relax() as used in the kernel also does a rep:nop which I
understand is the same opcode as pause, but for older assemblers
<janimo> not sure about apache's code
<ams> nop is a bit different than pause.
<janimo> ams, yes, but rep:nop is a special case that translates to the
pause op AIUI
<janimo> read yesterday, did not check myself
<ams> something like that..
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.