public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "dvhltc at us dot ibm dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sources.redhat.com
Subject: [Bug nptl/11588] pthread condvars are not priority inheritance aware
Date: Tue, 11 May 2010 18:56:00 -0000	[thread overview]
Message-ID: <20100511185548.14516.qmail@sourceware.org> (raw)
In-Reply-To: <20100511184557.11588.dvhltc@us.ibm.com>


------- Additional Comments From dvhltc at us dot ibm dot com  2010-05-11 18:55 -------
Created an attachment (id=4782)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4782&action=view)
pi condvar patch impact on normal path testcase

This test is designed to test the efficiency of the pthread_cond_wait() and
pthread_cond_signal() code paths within glibc. Ulrich has expressed concern
about these patches negatively impacting the non-pi condvar paths. I felt the
changes to the common case (when PI is not involved) were pretty minimal.
Certainly any significant regression there would be unacceptable.

I built three versions of glibc 2.11.1 from git:
1)	  git: unmodified git sources
2)     c_only: pthread_cond*.S files deleted
3) pi_condvar: same as c_only with the pi_condvar patches applied

Comparing #3 against #2 allows us to eliminate any gains #1 would have solely
from the hand written asm. 3 will eventually contain hand written asm, but
until the non-posix API is agreed upon, it doesn't make sense to expend the
effort of writing the asm code in my opinion.

I then ran 10 runs of 10M iterations each at SCHED_FIFO 1 priority on each of
the three glibcs, the results (following) suggest no significant change in the
non PI condvar performance, sitting right at ~270k (avg) cycles/sec for each
glibc.

build-x86_64-2.11.1-git
Cycles/Second: 279831.187500
Cycles/Second: 261911.421875
Cycles/Second: 277664.125000
Cycles/Second: 284847.718750
Cycles/Second: 285067.281250
Cycles/Second: 267918.718750
Cycles/Second: 284785.656250
Cycles/Second: 277402.843750
Cycles/Second: 202379.703125
Cycles/Second: 266421.718750

Min:  202379.703125  us
Max:  285067.28125  us
Avg:  268823.0375  us


build-x86_64-2.11.1-c_only
Cycles/Second: 277931.781250
Cycles/Second: 275614.093750
Cycles/Second: 271194.125000
Cycles/Second: 280155.093750
Cycles/Second: 284708.156250
Cycles/Second: 190936.031250
Cycles/Second: 264253.468750
Cycles/Second: 281354.281250
Cycles/Second: 290366.218750
Cycles/Second: 279962.000000

Min:  190936.03125  us
Max:  290366.21875  us
Avg:  269647.525  us


build-x86_64-2.11.1-pi_condvar
Cycles/Second: 263975.937500
Cycles/Second: 279577.281250
Cycles/Second: 276504.531250
Cycles/Second: 266163.562500
Cycles/Second: 262115.796875
Cycles/Second: 279219.406250
Cycles/Second: 265263.812500
Cycles/Second: 262226.468750
Cycles/Second: 284592.687500
Cycles/Second: 278975.875000

Min:  262115.796875  us
Max:  284592.6875  us
Avg:  271861.535938  us


This is only the cond_signal case, and doesn't account for cond_timedwait or
cond_broadcast, but I wouldn't expect those to experience any additional impact
from this patch. Are there scenarios you can think of that are likely to suffer
greater impact that are not covered by this rather simple test case?

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


  parent reply	other threads:[~2010-05-11 18:56 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-11 18:46 [Bug nptl/11588] New: " dvhltc at us dot ibm dot com
2010-05-11 18:48 ` [Bug nptl/11588] " dvhltc at us dot ibm dot com
2010-05-11 18:50 ` dvhltc at us dot ibm dot com
2010-05-11 18:51 ` dvhltc at us dot ibm dot com
2010-05-11 18:56 ` dvhltc at us dot ibm dot com [this message]
2010-05-12  5:02 ` dino at in dot ibm dot com
2010-05-12 11:06 ` pasky at suse dot cz
2010-05-13  1:55 ` dvhltc at us dot ibm dot com
2010-05-13  8:03 ` dvhltc at us dot ibm dot com
2010-05-13  8:05 ` dvhltc at us dot ibm dot com
2010-05-13  8:07 ` dvhltc at us dot ibm dot com
2010-05-13  8:08 ` dvhltc at us dot ibm dot com
2010-05-13  8:11 ` dvhltc at us dot ibm dot com
2010-05-13  8:13 ` dvhltc at us dot ibm dot com
2010-05-13 18:45 ` dvhltc at us dot ibm dot com
2010-05-27 23:19 ` dvhltc at us dot ibm dot com
2010-05-28 20:35 ` dvhltc at us dot ibm dot com
2010-06-17 20:59 ` dvhltc at us dot ibm dot com
2010-06-17 22:17 ` tglx at linutronix dot de
     [not found] <bug-11588-131@http.sourceware.org/bugzilla/>
2011-02-14 17:28 ` jan.kiszka at siemens dot com
2012-06-05 16:31 ` dvhart at linux dot intel.com
2012-06-05 16:37 ` jan.kiszka at siemens dot com
2012-10-25 11:03 ` triegel at redhat dot com
2012-12-19 10:51 ` schwab@linux-m68k.org
2013-01-19 16:13 ` scot4spam at yahoo dot com
2013-04-05 17:54 ` davidh at realtimeint dot com
2013-04-06  9:15 ` stano at meduna dot org
2013-10-17 21:16 ` gratian.crisan at ni dot com
2013-10-17 21:18 ` gratian.crisan at ni dot com
2013-10-17 21:22 ` gratian.crisan at ni dot com
2013-10-17 21:24 ` gratian.crisan at ni dot com
2013-11-15 17:36 ` gratian.crisan at ni dot com
2014-02-08  0:47 ` davidh at realtimeint dot com
2014-02-08  0:58 ` allan at archlinux dot org
2014-02-08  1:06 ` joseph at codesourcery dot com
2014-02-08  1:20 ` triegel at redhat dot com
2014-02-08  3:52 ` gratian.crisan at ni dot com
2014-02-10 23:00 ` darren.hart at intel dot com
2014-02-11  2:32 ` triegel at redhat dot com
2014-02-16 16:56 ` jackie.rosen at hushmail dot com
2014-02-20 17:44 ` john.ogness at linutronix dot de
2014-02-20 18:41 ` darren.hart at intel dot com
2014-02-20 18:42 ` darren.hart at intel dot com
2014-02-20 19:22 ` gratian.crisan at ni dot com
2014-02-21  8:44 ` john.ogness at linutronix dot de
2014-02-26 17:11 ` gratian.crisan at ni dot com
2014-03-31 19:31 ` darren.hart at intel dot com
2014-04-17 14:53 ` gratian.crisan at ni dot com
2014-04-17 15:15 ` darren.hart at intel dot com
2014-04-30 19:53 ` gratian.crisan at ni dot com
2014-05-28 19:42 ` schwab at sourceware dot org
2014-06-30 18:06 ` fweimer at redhat dot com
2014-07-07 20:39 ` gratian.crisan at ni dot com
2014-07-07 20:40 ` gratian.crisan at ni dot com
2014-07-07 20:41 ` gratian.crisan at ni dot com
2014-07-07 20:43 ` gratian.crisan at ni dot com
2014-07-07 20:44 ` gratian.crisan at ni dot com
2014-07-07 20:45 ` gratian.crisan at ni dot com
2014-10-02 21:57 ` davidh at realtimeint dot com
2014-10-06  7:57 ` triegel at redhat dot com
2020-07-06 14:05 ` carlos at redhat dot com
2021-08-23 13:32 ` will at eccles dot dev
2021-09-18 18:55 ` laurettastokes89 at gmail dot com
2021-10-21 15:42 ` fweimer at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100511185548.14516.qmail@sourceware.org \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).