[Bug nptl/13976] New: Possible enhancement in NPTL spin-lock code on x86 architectures: pause

["tschwinge at sourceware dot org" <sourceware-bugzilla at sourceware dot org>]

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.