From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52548 invoked by alias); 19 Aug 2015 13:42:47 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 52538 invoked by uid 89); 19 Aug 2015 13:42:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 19 Aug 2015 13:42:45 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 2CA7391E8F; Wed, 19 Aug 2015 13:42:44 +0000 (UTC) Received: from blade.nx (ovpn-116-91.ams2.redhat.com [10.36.116.91]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7JDghkj017436; Wed, 19 Aug 2015 09:42:43 -0400 Received: by blade.nx (Postfix, from userid 1000) id A1EB4262FAE; Wed, 19 Aug 2015 14:42:42 +0100 (BST) Date: Wed, 19 Aug 2015 13:42:00 -0000 From: Gary Benson To: Pedro Alves Cc: Sandra Loosemore , Joel Brobecker , Doug Evans , Jan Kratochvil , gdb-patches , =?iso-8859-1?Q?Andr=E9_P=F6nitz?= , Paul Koning Subject: Re: [PATCH 0/2] Better handling of slow remote transfers Message-ID: <20150819134242.GA18586@blade.nx> References: <20150811195943.GC22245@adacore.com> <20150812094831.GD11096@blade.nx> <20150814182648.GO22245@adacore.com> <55CE6AA3.8000300@codesourcery.com> <20150816184913.GA2998@adacore.com> <20150817085310.GC25320@blade.nx> <55D1EE96.9060202@codesourcery.com> <20150818095858.GB9815@blade.nx> <55D3625B.40101@codesourcery.com> <55D3DB83.4050204@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55D3DB83.4050204@redhat.com> X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00513.txt.bz2 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 > 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/