This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/13234] New: Non-pshared condition variables are ~2-2.5x slower than pshared ones at broadcast
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Wed, 28 Sep 2011 23:34:47 +0000
- Subject: [Bug nptl/13234] New: Non-pshared condition variables are ~2-2.5x slower than pshared ones at broadcast
- Auto-submitted: auto-generated
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.