Re: FYI GDB on-disk .debug cache (mmapcache) [Re: Tasks]

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> dwarf2_build_psymtabs_easy() should have been using the index
Jan> sections like `.debug_pubnames' but GDB has it #if 0-ed.

Just to recap here, I looked into this a little.  It does not look
very hard to write this code.  It might help, though I am not sure.


My test case was:

    gdb -nx -ex 'set pagination off' -batch-silent -p 25373

... where 25373 is the pid of an OpenOffice.org swriter process.

psymtab reading is a big chunk of the time, as measured by gprof
(oprofile basically agrees fwiw).

However, most of the elapsed time here is actually not in system or
user time -- I/O waits being the current contender (I did not try to
see this directly, so this is just a hypothesis).  I see fairly
consistent results like this (from /usr/bin/time) on a reasonably
quiescent system:

24.63user 2.67system 1:02.00elapsed 44%CPU (0avgtext+0avgdata 0maxresident)k
880504inputs+0outputs (4major+170415minor)pagefaults 0swaps

(On irc Roland asked about disk cache effects ... the amount of memory
available for the cache, as reported by whatever that Gnome panel
applet is, shrinks steadily -- this test uses most of the available
memory on this machine.  Running this on a bigger box might prove
interesting.)


There seem to be a few possible smaller optimization opportunities:

* Maybe delaying psymtab symbol sorting would save some cycles in the
  plain attach case -- this only defers it until later, but that might
  be good enough in some situations.  (I'm thinking -- there is some
  minimum amount of work we will have to do.  Spreading it out and
  making it conditional on the user actually needing it is friendlier.
  But, at some point presumably you just have to settle.)

* Better even would be to lazily load everything; it seems like we'll
  want that for multi-process anyhow.  Again, this just defers work.

* Maybe we could play some trick to speed up strcmp_iw_ordered.

I think these won't amount to much though.  Half the elapsed time is
unaccounted for.

Jan> My idea was some on-disk cache, created on-demand in ~/.gdb_cache . There
Jan> could also be some system-wide rpm debuginfo packages cache created in
Jan> /usr/lib/debug during rpm %post by `gdb --readnow'.

This is an interesting idea, though I find it a bit hard to reconcile
with the I/O wait theory.  Perhaps we would be reading strictly less
data.

Jan> With my patch the CPU usage while loading the stored cache file
Jan> dropped from ~60% to about 3% but still it was ~26s and with disk
Jan> seeking all the time.
[...]
Jan> The CPU power is so cheap and also the disk read bandwidth is
Jan> cheap, just the disk seek is the culprit.

Yeah, I think that would explain what I'm seeing.

Anyway, I plan to do some more investigation.  I'm interested in your
thoughts.

thanks,
Tom