Message ID | 1439389814-29211-1-git-send-email-gbenson@redhat.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 85581 invoked by alias); 12 Aug 2015 14:30:23 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 85534 invoked by uid 89); 12 Aug 2015 14:30:22 -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 14:30:17 +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 32EE891EB0; Wed, 12 Aug 2015 14:30:16 +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 t7CEUFpi021601; Wed, 12 Aug 2015 10:30:15 -0400 Received: from blade.nx (localhost [127.0.0.1]) by blade.nx (Postfix) with ESMTP id A50822643BD; Wed, 12 Aug 2015 15:30:14 +0100 (BST) From: Gary Benson <gbenson@redhat.com> To: gdb-patches@sourceware.org Cc: Sandra Loosemore <sandra@codesourcery.com>, Pedro Alves <palves@redhat.com>, Doug Evans <dje@google.com> Subject: [PATCH] Make remote transfers interruptible Date: Wed, 12 Aug 2015 15:30:14 +0100 Message-Id: <1439389814-29211-1-git-send-email-gbenson@redhat.com> In-Reply-To: <55C3A10F.3010106@codesourcery.com> References: <55C3A10F.3010106@codesourcery.com> X-IsSubscribed: yes |
Commit Message
Gary Benson
Aug. 12, 2015, 2:30 p.m. UTC
Hi Sandra, Sandra Loosemore wrote: > On 08/05/2015 09:28 AM, Gary Benson wrote: > > This commit makes it possible to interrupt slow remote file transfers. > > > > gdb/ChangeLog: > > > > * gdb_bfd.c (gdb_bfd_iovec_fileio_pread): Add QUIT call. > > It still does not work for me. :-( Could you please try this newer version and see if it allows you to interrupt the remote transfers? Thanks, Gary ---
Comments
On 08/12/2015 08:30 AM, Gary Benson wrote: > Hi Sandra, > > Sandra Loosemore wrote: >> On 08/05/2015 09:28 AM, Gary Benson wrote: >>> This commit makes it possible to interrupt slow remote file transfers. >>> >>> gdb/ChangeLog: >>> >>> * gdb_bfd.c (gdb_bfd_iovec_fileio_pread): Add QUIT call. >> >> It still does not work for me. :-( > > Could you please try this newer version and see if it allows you to > interrupt the remote transfers? This version still doesn't make the transfer interruptable with ^C. *But*, with this patch, the startup time is reduced from 4 minutes to 19 seconds. Huh? Is it really transferring the entire file contents, or was the time being used for some GDB-side operation that is quadratic or exponential in the size of the read requested rather than the actual byte transfer? Independently of the ^C issue, I think we need to better understand what is going on here and better tune the code on both sides of the RSP for large file transfers. Even if a user asks for target-side libraries explicitly, 4 minutes to transfer one library doesn't provide a good user experience, and 19 seconds isn't so great either when you consider that some interactive applications link with dozens of GUI or multimedia libraries and not just glibc. -Sandra
On Wed, Aug 12, 2015 at 10:31 AM, Sandra Loosemore <sandra@codesourcery.com> wrote: > On 08/12/2015 08:30 AM, Gary Benson wrote: >> >> Hi Sandra, >> >> Sandra Loosemore wrote: >>> >>> On 08/05/2015 09:28 AM, Gary Benson wrote: >>>> >>>> This commit makes it possible to interrupt slow remote file transfers. >>>> >>>> gdb/ChangeLog: >>>> >>>> * gdb_bfd.c (gdb_bfd_iovec_fileio_pread): Add QUIT call. >>> >>> >>> It still does not work for me. :-( >> >> >> Could you please try this newer version and see if it allows you to >> interrupt the remote transfers? > > > This version still doesn't make the transfer interruptable with ^C. *But*, > with this patch, the startup time is reduced from 4 minutes to 19 seconds. > Huh? Is it really transferring the entire file contents, or was the time > being used for some GDB-side operation that is quadratic or exponential in > the size of the read requested rather than the actual byte transfer? > Independently of the ^C issue, I think we need to better understand what is > going on here and better tune the code on both sides of the RSP for large > file transfers. Even if a user asks for target-side libraries explicitly, 4 > minutes to transfer one library doesn't provide a good user experience, and > 19 seconds isn't so great either when you consider that some interactive > applications link with dozens of GUI or multimedia libraries and not just > glibc. Dozens? How about thousands. 1/2 :-) [just want to make sure such cases are in the mindset of the community]
Sandra Loosemore wrote: > On 08/12/2015 08:30 AM, Gary Benson wrote: > >Sandra Loosemore wrote: > > >On 08/05/2015 09:28 AM, Gary Benson wrote: > > > > This commit makes it possible to interrupt slow remote file > > > > transfers. > > > > > > > > gdb/ChangeLog: > > > > > > > > * gdb_bfd.c (gdb_bfd_iovec_fileio_pread): Add QUIT call. > > > > > > It still does not work for me. :-( > > > > Could you please try this newer version and see if it allows you > > to interrupt the remote transfers? > > This version still doesn't make the transfer interruptable with ^C. Then I am out of ideas :( I can interrupt on my setup with either patch (I tested it by adding a 100ms usleep in gdbserver/hostio.c handle_pread). I will push a warning-printing patch to HEAD, so that users in your situation at least have some feedback on what is happening. Could you please look at making the transfers interruptible? Joel, would you like me to also push it to the 7.10 branch, or will you do that? > *But*, with this patch, the startup time is reduced from 4 minutes > to 19 seconds. Huh? Is it really transferring the entire file > contents, or was the time being used for some GDB-side operation > that is quadratic or exponential in the size of the read requested > rather than the actual byte transfer? Independently of the ^C > issue, I think we need to better understand what is going on here > and better tune the code on both sides of the RSP for large file > transfers. That's pretty weird. It sounds like there's real scope for you to improve performance here. Thanks, Gary
> Joel, would you like me to also push it to the 7.10 branch, or will > you do that? Just answering in a general way: Any Global Maintainer has authority to approve a patch for a release branch; and once approve, you can cherry-pick yourself and apply to the branch. Not a problem.
On 08/12/2015 06:31 PM, Sandra Loosemore wrote: > On 08/12/2015 08:30 AM, Gary Benson wrote: >> Hi Sandra, >> >> Sandra Loosemore wrote: >>> On 08/05/2015 09:28 AM, Gary Benson wrote: >>>> This commit makes it possible to interrupt slow remote file transfers. >>>> >>>> gdb/ChangeLog: >>>> >>>> * gdb_bfd.c (gdb_bfd_iovec_fileio_pread): Add QUIT call. >>> >>> It still does not work for me. :-( >> >> Could you please try this newer version and see if it allows you to >> interrupt the remote transfers? > > This version still doesn't make the transfer interruptable with ^C. > *But*, with this patch, the startup time is reduced from 4 minutes to 19 > seconds. Huh? Is it really transferring the entire file contents, or > was the time being used for some GDB-side operation that is quadratic or > exponential in the size of the read requested rather than the actual > byte transfer? Independently of the ^C issue, I think we need to better > understand what is going on here and better tune the code on both sides > of the RSP for large file transfers. Even if a user asks for > target-side libraries explicitly, 4 minutes to transfer one library > doesn't provide a good user experience, and 19 seconds isn't so great > either when you consider that some interactive applications link with > dozens of GUI or multimedia libraries and not just glibc. > Now that's quite surprising. It seems to make no difference to me. Granted, I'm testing on the local machine, but, attaching to Firefox, with: $ ./gdbserver/gdbserver --multi :9999 and then: $ ./gdb -data-directory=data-directory -ex "tar extended-rem :9999" -ex "set pagination off" -ex "attach 31613" -ex "info shared" -ex "set confirm off" -ex "detach" -ex "quit" takes around 3-5 seconds with or without patch. Around one second less if I do (add "set sysroot /"): $ ./gdb -data-directory=data-directory -ex "set sysroot /" -ex "tar extended-rem :9999" -ex "set pagination off" -ex "attach 31613" -ex "info shared" -ex "set confirm off" -ex "detach" -ex "quit" I was previously assuming you were seeing this on multiple machines, but looking back, I only find mention of nios2. Could it be the slowdown you see is caused by some other local patches you might have in the tree you're using? Do you see it with pristine FSF? If you try your example test with gdb 7.9, with "set sysroot remote:", does it also take the 4 minutes to reach main? Also, can you reproduce this with other machines? E.g., what about x86_64 GNU/Linux? Wondering whether it's a kernel/libc/etc issue... Does anyone else confirm the unexpected slowness Sandra is seeing? Thanks, Pedro Alves
On 08/17/2015 10:00 AM, Pedro Alves wrote: > > I was previously assuming you were seeing this on multiple machines, > but looking back, I only find mention of nios2. > > Could it be the slowdown you see is caused by some other local patches > you might have in the tree you're using? Do you see it with pristine FSF? I initially saw this in a local branch, but I have been very careful to reproduce and test things with an unmodified FSF checkout. > If you try your example test with gdb 7.9, with "set sysroot remote:", > does it also take the 4 minutes to reach main? > > Also, can you reproduce this with other machines? E.g., what about > x86_64 GNU/Linux? Wondering whether it's a kernel/libc/etc issue... The other Linux-target build I have handy for testing right now is arm-none-linux-gnueabi with unmodified FSF head, testing on a PandaBoard. There I found it takes about 8 seconds to start up the same hello-world program that takes 4 minutes on Nios II with the new sysroot default, and < 1 second if I do "set sysroot" first. Aside from possible kernel issues or whatever, the Nios II board is theoretically a factor of 20 slower than the PandaBoard (processor supposedly clocked at 10Mhz, and only one core versus 1Ghz and 2 cores for the PandaBoard), and the libc.so it's transferring is larger. -Sandra
diff --git a/gdb/remote.c b/gdb/remote.c index 69da508..7db1e25 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -10378,12 +10378,11 @@ remote_hostio_pwrite (struct target_ops *self, remote_errno, NULL, NULL); } -/* Implementation of to_fileio_pread. */ +/* Helper for remote_hostio_pread. */ static int -remote_hostio_pread (struct target_ops *self, - int fd, gdb_byte *read_buf, int len, - ULONGEST offset, int *remote_errno) +remote_hostio_pread_1 (int fd, gdb_byte *read_buf, int len, + ULONGEST offset, int *remote_errno) { struct remote_state *rs = get_remote_state (); char *p = rs->buf; @@ -10417,6 +10416,37 @@ remote_hostio_pread (struct target_ops *self, return ret; } +/* Implementation of to_fileio_pread. */ + +static int +remote_hostio_pread (struct target_ops *self, + int fd, gdb_byte *read_buf, int len, + ULONGEST offset, int *remote_errno) +{ + gdb_byte *buf = read_buf; + + while (len > 0) + { + int ret; + + QUIT; + + ret = remote_hostio_pread_1 (fd, buf, min (len, 4096), offset, + remote_errno); + if (ret < 0) + return ret; + + if (ret == 0) + break; + + buf += ret; + offset += ret; + len -= ret; + } + + return buf - read_buf; +} + /* Implementation of to_fileio_close. */ static int