Re: [PATCH 0/2] Better handling of slow remote transfers

Gary Benson
2015-08-19T13:42:47Z

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

--