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.
next prev 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: linkBe 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).