From: Markus Alber <markus@hyperion-imrt.org>
To: Tom Tromey <tromey@redhat.com>
Cc: Pedro Alves <pedro@codesourcery.com>, <gdb@sourceware.org>,
Ulrich Weigand <uweigand@de.ibm.com>,
Michael Snyder <msnyder@vmware.com>, <gdb-patches@sourceware.org>
Subject: Re: performance of multithreading gets gradually worse under gdb
Date: Mon, 07 Feb 2011 14:05:00 -0000 [thread overview]
Message-ID: <669a4377e86b8bb38a8ab765164aae23@hyperion-imrt.org> (raw)
In-Reply-To: <m3hbcjag3e.fsf@fleche.redhat.com>
On Fri, 04 Feb 2011 10:01:57 -0700, Tom Tromey wrote:
> Tom> Yeah, this looks reasonable to me.
>
> Pedro> Okay, thanks, I've applied it.
>
> Thanks
>
> Markus -- any way you could try gdb CVS HEAD to see if it fixes your
> problem? If it doesn't, then there are more bugs to find...
>
> Tom
Hi, I did as told and it does indeed make the situation a lot better.
The application runs to the end (for the first time!) and it does not
slow down.
Thanks for that!
The application is a lot slower though when run in gdb, than
stand-alone.
I think the reason is this. During each iteration, it branches into the
worker threads and then comes back to some part of the computation
which
is performed only by one CPU. With 12 cores, the time per iteration is
essentially spent in there. It is here that gdb competes with the
application,
because both seem to be running on the same core. The average load
drops from
66% to about 20% when run in gdb.
Just for your information/in case you are interested.
I did an oprofile as well, and here is what it says:
samples % image name app name
symbol name
1113 19.3464 libthread_db-1.0.so libthread_db-1.0.so
_td_locate_field
1054 18.3209 libthread_db-1.0.so libthread_db-1.0.so
td_thr_get_info
847 14.7228 libthread_db-1.0.so libthread_db-1.0.so
td_ta_event_getmsg
804 13.9753 libthread_db-1.0.so libthread_db-1.0.so
_td_fetch_value_local
568 9.8731 libthread_db-1.0.so libthread_db-1.0.so
td_ta_map_lwp2thr
519 9.0214 libthread_db-1.0.so libthread_db-1.0.so
_td_fetch_value
484 8.4130 libthread_db-1.0.so libthread_db-1.0.so
__td_ta_lookup_th_unique
169 2.9376 libthread_db-1.0.so libthread_db-1.0.so
_td_store_value
167 2.9028 libthread_db-1.0.so libthread_db-1.0.so
td_thr_event_enable
3 0.0521 iconv iconv
/usr/bin/iconv
3 0.0521 libstreamanalyzer.so.0.7.2 libstreamanalyzer.so.0.7.2
/usr/lib64/libstreamanalyzer.so.0.7.2
2 0.0348 [vdso] (tgid:2539
range:0x7fffe81ff000-0x7fffe8200000) auditd [vdso]
(tgid:2539 range:0x7fffe81
200000)
2 0.0348 libpcre.so.0.0.1 libpcre.so.0.0.1
/lib64/libpcre.so.0.0.1
2 0.0348 ophelp ophelp
/usr/bin/ophelp
1 0.0174 [vdso] (tgid:7680
range:0x7fff267c6000-0x7fff267c7000) kdeinit4 [vdso]
(tgid:7680 range:0x7fff267
7c7000)
1 0.0174 [vdso] (tgid:8945
range:0x7fffbbbff000-0x7fffbbc00000) gconfd-2 [vdso]
(tgid:8945 range:0x7fffbbb
c00000)
1 0.0174 auditd auditd
/sbin/auditd
1 0.0174 basename basename
/bin/basename
1 0.0174 kded_networkstatus.so kded_networkstatus.so
/usr/lib64/kde4/kded_networkstatus.so
1 0.0174 libXau.so.6.0.0 libXau.so.6.0.0
/usr/lib64/libXau.so.6.0.0
1 0.0174 libXi.so.6.1.0 libXi.so.6.1.0
/usr/lib64/libXi.so.6.1.0
1 0.0174 libkdeinit4_kglobalaccel.so
libkdeinit4_kglobalaccel.so /usr/lib64/libkdeinit4_kglobalaccel.so
1 0.0174 libstreams.so.0.7.2 libstreams.so.0.7.2
/usr/lib64/libstreams.so.0.7.2
1 0.0174 libthread_db-1.0.so libthread_db-1.0.so
__do_global_ctors_aux
1 0.0174 pickup pickup
/usr/lib/postfix/pickup
1 0.0174 plasma_applet_icon.so plasma_applet_icon.so
/usr/lib64/kde4/plasma_applet_icon.so
1 0.0174 qmgr qmgr
/usr/lib/postfix/qmgr
1 0.0174 rpcbind rpcbind
/sbin/rpcbind
1 0.0174 sleep sleep
/bin/sleep
1 0.0174 touch touch
/bin/touch
If you want to have it in more detail, please tell me what options
you'd like to have engaged.
regards,
Markus
next prev parent reply other threads:[~2011-02-07 14:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <201102032140.p13Le89f031563@d06av02.portsmouth.uk.ibm.com>
[not found] ` <201102041455.20607.pedro@codesourcery.com>
[not found] ` <m34o8jddod.fsf@fleche.redhat.com>
2011-02-04 15:56 ` Pedro Alves
2011-02-04 15:58 ` Pedro Alves
2011-10-26 17:20 ` [patch] Multi-architecture debugging regression (Re: performance of multithreading gets gradually worse under gdb) Ulrich Weigand
2011-10-26 17:25 ` Pedro Alves
2011-10-26 18:14 ` Ulrich Weigand
[not found] ` <201102041555.52179.pedro__21913.9744448059$1296834976$gmane$org@codesourcery.com>
2011-02-04 17:02 ` performance of multithreading gets gradually worse under gdb Tom Tromey
2011-02-05 9:34 ` Markus Alber
2011-02-07 14:05 ` Markus Alber [this message]
[not found] <201102041349.p14DnCeY025641@d06av02.portsmouth.uk.ibm.com>
2011-02-04 14:50 ` Tom Tromey
2011-02-04 14:58 ` Ulrich Weigand
2011-02-04 15:01 ` Pedro Alves
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=669a4377e86b8bb38a8ab765164aae23@hyperion-imrt.org \
--to=markus@hyperion-imrt.org \
--cc=gdb-patches@sourceware.org \
--cc=gdb@sourceware.org \
--cc=msnyder@vmware.com \
--cc=pedro@codesourcery.com \
--cc=tromey@redhat.com \
--cc=uweigand@de.ibm.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