From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22301 invoked by alias); 27 Dec 2014 17:09:03 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org Received: (qmail 22267 invoked by uid 48); 27 Dec 2014 17:09:02 -0000 From: "mrsam@courier-mta.com" To: gdb-prs@sourceware.org Subject: [Bug gdb/17764] Excessive seeking when reading debug data pegs the CPU @100% Date: Sat, 27 Dec 2014 17:09:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: 7.8 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mrsam@courier-mta.com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-q4/txt/msg00451.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17764 --- Comment #3 from Sam Varshavchik --- The .so's total size is 60 megabytes. readelf shows all the debug data starting at about the 14 megabyte mark, so, say around 46 megs of debug data, give or take a meg. I monitored the virtual memory size of the gdb process itself, while it was spinning. gdb was not allocating an appreciable amount of memory. gdb-add-index grew the .so to 70 megs in size, but made no visible difference -- gdb still pegged the CPU for over a minute at startup. One thing I've noticed is that gdb seems to be rereading the same debug data over and over again. If I grep just the seek offsets, the remove the consecutive dupes only, then sort the deduped list again, I still find that the gdb process often re-seeks back to the same offset, something like this: grep lseek | awk ' { print $2 } ' | uniq | sort | uniq -c Partial results from this: 926 8769536, 926 8773632, 926 8777728, 925 8781824, 888 8785920, 632 8790016, 376 8794112, 120 8798208, So, it seems like after reading from seek offset 8769536, for example, the gdb process then seeked somewhere else, but at some point went back and reread it again. Almost a thousand times. This is with the gdb-add-index data in the .so; but, again, that took about the same amount of time as without it. -- You are receiving this mail because: You are on the CC list for the bug.