This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 0/2] Better handling of slow remote transfers
- From: Gary Benson <gbenson at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Sandra Loosemore <sandra at codesourcery dot com>, Joel Brobecker <brobecker at adacore dot com>, Doug Evans <dje at google dot com>, Jan Kratochvil <jan dot kratochvil at redhat dot com>, gdb-patches <gdb-patches at sourceware dot org>, André Pönitz <apoenitz at t-online dot de>, Paul Koning <Paul_Koning at dell dot com>
- Date: Wed, 19 Aug 2015 14:42:42 +0100
- Subject: Re: [PATCH 0/2] Better handling of slow remote transfers
- Authentication-results: sourceware.org; auth=none
- References: <20150811195943 dot GC22245 at adacore dot com> <20150812094831 dot GD11096 at blade dot nx> <20150814182648 dot GO22245 at adacore dot com> <55CE6AA3 dot 8000300 at codesourcery dot com> <20150816184913 dot GA2998 at adacore dot com> <20150817085310 dot GC25320 at blade dot nx> <55D1EE96 dot 9060202 at codesourcery dot com> <20150818095858 dot GB9815 at blade dot nx> <55D3625B dot 40101 at codesourcery dot com> <55D3DB83 dot 4050204 at redhat dot com>
Pedro Alves wrote:
> BTW, the transfers seem to be always interruptible for me, even without
> Gary's patch, and even the slow ones.
Ok, I'm glad I'm not the only one :)
> From d426ce0a36830378a8ec2e2cbdd94d9fcb47b891 Mon Sep 17 00:00:00 2001
> From: Pedro Alves <palves@redhat.com>
> Date: Tue, 18 Aug 2015 23:27:20 +0100
> Subject: [PATCH 3/3] add readahead cache to gdb's vFile:pread
I tried this out on its own, and got similar hit/miss ratios, so it
looks like a good addition. Comments below.
> diff --git a/gdb/remote.c b/gdb/remote.c
> index a839adf..8a739c8 100644
> --- a/gdb/remote.c
> +++ b/gdb/remote.c
> @@ -10311,6 +10311,26 @@ remote_hostio_send_command (int command_bytes, int which_packet,
> return ret;
> }
>
> +struct readahead_cache
> +{
> + int fd;
> + gdb_byte *buf;
> + ULONGEST offset;
> + size_t bufsize;
> +};
> +
> +static struct readahead_cache *readahead_cache;
Would this be better in struct remote_state (and maybe not allocated,
just inlined in the main remote_state--it's only 16 or 32 bytes)?
> @@ -10325,6 +10345,8 @@ remote_hostio_set_filesystem
> char arg[9];
> int ret;
>
> + readahead_cache_invalidate ();
> +
> if (packet_support (PACKET_vFile_setfs) == PACKET_DISABLE)
> return 0;
>
This isn't necessary, file descriptors persist across setns calls.
> + if (remote_debug)
> + fprintf_unfiltered (gdb_stdlog,
> + "readahead cache hit %d\n",
> + ++readahead_cache_hit_count);
and
> + if (remote_debug)
> + fprintf_unfiltered (gdb_stdlog, "readahead cache miss %d\n",
> + ++readahead_cache_miss_count);
These only update the counters when debug printing is switched on.
Is this what you intended?
> Looking at "set debug remote 1" output, I noticed that gdb often
> issues a sequence of small vFile:pread requests for the same file.
> Ctrl-c'ing gdb while it was doing that and getting a backtrace shows
> that those requests often came from bfd. So I thought that maybe
> adding a readahead buffer/cache to gdb's vFile:pread requests could
> help. And indeed, that dropped the time for the same use case
> further down to:
Another thing I noticed when I was testing the warning messages patch
is that GDB seems to (always? often?) open each file twice:
Remote debugging using :9999
* Reading /home/gary/work/archer/fast-transfer/build64/gdb/gdbserver/gdbserver from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" with no arguments to access files locally instead.
* Reading /home/gary/work/archer/fast-transfer/build64/gdb/gdbserver/gdbserver from remote target...
Reading symbols from target:/home/gary/work/archer/fast-transfer/build64/gdb/gdbserver/gdbserver...done.
* Reading /lib64/ld-linux-x86-64.so.2 from remote target...
* Reading /lib64/ld-linux-x86-64.so.2 from remote target...
...etc
Figuring out why this is happening could save us some more time.
Cheers,
Gary
--
http://gbenson.net/