public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
To: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH v2 0/8] Demangle minimal symbol names in worker threads
Date: Sun, 19 May 2019 13:59:00 -0000	[thread overview]
Message-ID: <1558274338.1454.13.camel@skynet.be> (raw)
In-Reply-To: <20190518210010.27697-1-tom@tromey.com>

On Sat, 2019-05-18 at 15:00 -0600, Tom Tromey wrote:
> This is v2 of my patch series to demangle minimal symbol names in
> worker threads.
> 
> v1 was here:
> 
>     https://sourceware.org/ml/gdb-patches/2019-03/msg00211.html
> 
> I think this version addresses all the comments, in particular it adds
> a simple way to disable threading, and adds some configury.
> 
> Regression tested by the buildbot.  At one point this was failing most
> tests on the i686 builder, but I couldn't reproduce this with my own
> i686 build (on the GCC compile farm), and various checks involving
> running parts of the test suite on the buildbot using valgrind did not
> show anything.  In the end, the problem seems to have gone away
> (though there are many gdb.arch failures on i686 -- assertion failures
> in libopcodes).  So, I'm not totally sure what to make of this.
That looks like a nice startup speed improvement, will be much appreciated
when debugging big executables at work :).

HEAD:
time ../build_binutils-gdb/gdb/gdb --nx -batch -ex 'info var tructructruc' ./gdb/gdb
...
real	0m3.902s
user	0m3.068s
sys	0m0.836s

worker thread patch:
time ./gdb/gdb --nx -batch -ex 'info var tructructruc' ./gdb/gdb
...
real	0m2.379s
user	0m2.172s
sys	0m0.284s


I however do not observe much parallel CPU being used.
What type of operations will be mostly helped by parallel threads ?


One comment about 'maint set|show enable-threads' :
what is the reason to have this as a maintenance command ?
Also, maybe it would be better to have this setting being the
maximum nr of threads to use.  In some environments (e.g.
operational environments), one might want to limit the nr of threads
used by GDB.
So, maybe 'maint set enable-threads' might be replaced by something like:
   set max-gdb-threads (NUMBER | unlimited)
where unlimited means to use the max permitted by the implementation
(or similar wording as in std::thread::hardware_concurrency),
and where 0 will disable threading.

Note also that I see GDB is starting some threads by default
when guile is configured in, and 'maint set enable-threads off'
seems to not disable this type of threading.

Thanks

Philippe


  parent reply	other threads:[~2019-05-19 13:59 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-18 21:00 Tom Tromey
2019-05-18 21:00 ` [PATCH v2 8/8] Add maint set/show enable-threads Tom Tromey
2019-05-22  5:01   ` Eli Zaretskii
2019-05-26 20:46     ` Tom Tromey
2019-05-27  2:32       ` Eli Zaretskii
2019-05-18 21:00 ` [PATCH v2 7/8] Demangle minsyms in parallel Tom Tromey
2019-05-18 21:00 ` [PATCH v2 6/8] Introduce thread-safe way to handle SIGSEGV Tom Tromey
2019-05-18 21:00 ` [PATCH v2 2/8] Remove static buffer from ada_decode Tom Tromey
2019-05-18 21:00 ` [PATCH v2 3/8] Add configure check for std::thread Tom Tromey
2019-05-18 21:00 ` [PATCH v2 1/8] Defer minimal symbol name-setting Tom Tromey
2019-05-18 21:00 ` [PATCH v2 5/8] Introduce run_on_main_thread Tom Tromey
2019-05-18 21:00 ` [PATCH v2 4/8] Lock the demangled hash table Tom Tromey
2019-05-19 13:59 ` Philippe Waroquiers [this message]
2019-05-19 18:55   ` [PATCH v2 0/8] Demangle minimal symbol names in worker threads Tom Tromey
2019-05-21  0:35     ` Philippe Waroquiers
2019-05-21  7:35     ` Andrew Burgess
2019-05-21 15:45       ` Tom Tromey
2019-05-21 16:21         ` Andrew Burgess
2019-05-31  2:48     ` Tom Tromey
2019-05-31 17:13       ` Philippe Waroquiers
2019-09-29  0:35         ` [PATCH] Don't use the mutex for each symbol_set_names call Christian Biesinger via gdb-patches
2019-09-30 14:18           ` Tom Tromey
2019-09-30 16:55             ` Christian Biesinger via gdb-patches
2019-10-02 17:18               ` Tom Tromey
2019-10-02 18:20                 ` Christian Biesinger via gdb-patches
2019-10-02 22:02                   ` Christian Biesinger via gdb-patches
2019-10-03 18:15                     ` [PATCH v2 1/2] " Christian Biesinger via gdb-patches
2019-10-03 18:15                     ` [PATCH v2 2/2] Precompute hash value for symbol_set_names Christian Biesinger via gdb-patches
2019-09-30 21:45             ` [PATCH] Don't use the mutex for each symbol_set_names call Christian Biesinger via gdb-patches
2019-10-01 17:02               ` Tom Tromey

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=1558274338.1454.13.camel@skynet.be \
    --to=philippe.waroquiers@skynet.be \
    --cc=gdb-patches@sourceware.org \
    --cc=tom@tromey.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).