[Bug nptl/13234] New: Non-pshared condition variables are ~2-2.5x slower than pshared ones at broadcast

["bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=13234

             Bug #: 13234
           Summary: Non-pshared condition variables are ~2-2.5x slower
                    than pshared ones at broadcast
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: bugdal@aerifal.cx
    Classification: Unclassified


Created attachment 5950
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5950
Test program which exhibits performance difference pshared/non-pshared.

The attached program shows NPTL's non-process-shared condition variables (which
utilize futex requeue) performing significantly worse than process-shared ones
(which simply use a broadcast futex wake). On my machine (Atom N280 dual core)
it takes ~11.7 seconds with non-pshared cond var and ~5.3 seconds with a
pshared cond var (comment/uncomment the pthread_cond_init line to change which
is used).

Of course requeue-based broadcast should scale better to huge numbers of
waiters. This test program only has 5 waiters. Still, the performance should
not be this bad. With musl libc, I get comparable performance with pshared and
non-pshared cond var (and both ways outperform NPTL, with run times around
2.5-3 seconds).

If you're unwilling to properly fix whatever's making it slow, perhaps just
using a broadcast futex wake rather than the requeue code whenever the number
of waiters is less than ~10 would be an easy "fix"...

BTW, I suspect the overly-complex sequencing code aimed at minimizing spurious
wakes, which also seems responsible for bugs 12875 and 13165, is probably part
of the problem...

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