This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/19828] 7.11 regression: non-stop gdb -p <process from a container>: internal error
- From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Tue, 24 May 2016 13:55:36 +0000
- Subject: [Bug gdb/19828] 7.11 regression: non-stop gdb -p <process from a container>: internal error
- Auto-submitted: auto-generated
- References: <bug-19828-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=19828
--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pedro Alves <palves@sourceware.org>:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1ad3de988d2f41c72de66613c68ed78507a3abbd
commit 1ad3de988d2f41c72de66613c68ed78507a3abbd
Author: Pedro Alves <palves@redhat.com>
Date: Tue May 24 14:47:57 2016 +0100
[Linux] Avoid refetching core-of-thread if thread hasn't run
Hacking the gdb.threads/attach-many-short-lived-threads.exp test to
spawn thousands of threads instead of dozens, I saw GDB having trouble
keeping up with threads being spawned too fast, when it tried to stop
them all. This was because while gdb is doing that, it updates the
thread list to make sure no new thread has sneaked in that might need
to be paused. It does this a few times until it sees no-new-threads
twice in a row. The thread listing update itself is not that
expensive, however, in the Linux backend, updating the threads list
calls linux_common_core_of_thread for each LWP to record on which core
each LWP was last seen running, which opens/reads/closes a /proc file
for each LWP which becomes expensive when you need to do it for
thousands of LWPs.
perf shows gdb in linux_common_core_of_thread 44% of the time, in the
stop_all_threads -> update_thread_list path in this use case.
This patch simply makes linux_common_core_of_thread avoid updating the
core the thread is bound to if the thread hasn't run since the last
time we updated that info. This makes linux_common_core_of_thread
disappear into the noise in the perf report.
gdb/ChangeLog:
2016-05-24 Pedro Alves <palves@redhat.com>
PR gdb/19828
* linux-nat.c (linux_resume_one_lwp_throw): Clear the LWP's core
field.
(linux_nat_update_thread_list): Don't fetch the core if already
known.
--
You are receiving this mail because:
You are on the CC list for the bug.