From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42012 invoked by alias); 12 Aug 2015 15:45:32 -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 42001 invoked by uid 89); 12 Aug 2015 15:45:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 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, 12 Aug 2015 15:45:31 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 4727A98C29; Wed, 12 Aug 2015 15:45:30 +0000 (UTC) Received: from blade.nx (ovpn-116-40.ams2.redhat.com [10.36.116.40]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7CFjTPA011893; Wed, 12 Aug 2015 11:45:29 -0400 Received: by blade.nx (Postfix, from userid 1000) id F132F264517; Wed, 12 Aug 2015 16:45:27 +0100 (BST) Date: Wed, 12 Aug 2015 15:45:00 -0000 From: Gary Benson To: Pedro Alves Cc: Joel Brobecker , Doug Evans , Jan Kratochvil , gdb-patches , Sandra Loosemore , =?iso-8859-1?Q?Andr=E9_P=F6nitz?= , Paul Koning Subject: Re: [PATCH 0/2] Better handling of slow remote transfers Message-ID: <20150812154527.GA17919@blade.nx> References: <55CB2DF8.2050506@redhat.com> <20150812123254.GA14726@blade.nx> <55CB4150.6090807@redhat.com> <20150812130248.GA15429@blade.nx> <55CB4B74.3070204@redhat.com> <20150812133825.GA25961@blade.nx> <55CB5119.9070504@redhat.com> <55CB5BDA.3020904@redhat.com> <20150812150841.GA20824@blade.nx> <55CB66DE.5040203@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55CB66DE.5040203@redhat.com> X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00292.txt.bz2 Pedro Alves wrote: > On 08/12/2015 04:08 PM, Gary Benson wrote: > > Pedro Alves wrote: > > > On 08/12/2015 02:58 PM, Pedro Alves wrote: > > > > GDB will usually cap the transfers to before they get to the > > > > lower layers. E.g., look for 4096 in memory_xfer_partial, > > > > target_read_alloc_1 and target_fileio_read_alloc_1. > > > > > > > > As this request is coming from the BFD side, we should > > > > probably make remote_hostio_pread also cap the size of the > > > > vFile:pread request. A reasonable number like a few KBs > > > > should not introduce any noticeable slow down. > > > > > > But wait, I'm now confused -- isn't this a red herring? Since > > > gdbserver is already limiting transfers to PBUFSIZE, this change > > > should have no practical effect, right? > > > > > > How can BFD's large remote_hostio_pread result in large > > > vFile:pread: packet responses then? > > > > I think gdbserver is returning multiple packets but something in > > GDB (getpkt_or_notif_sane_1?) is concatenating them together > > somehow. > > No, getpkt_or_notif_sane_1 will return as soon as it has a single > packet, which should then be bubbling up the layers and reaching > gdb_bfd_iovec_fileio_pread. Something else is going on. Either the > QUIT is being lost/eaten, or ... hmm ... maybe the SIGINT handler is > set to remote.c:async_handle_remote_sigint when the ctrl-c is typed, > which means the ctrl-c doesn't actually set_quit_flag()? I've no idea. Really I haven't. I have to finish for the day now. I'll be back in 16 hours. Maybe somebody who'll benefit from interruptible remote transfers could look into this while I'm away. Sandra? Pedro? Doug? Thanks, Gary -- http://gbenson.net/