From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64011 invoked by alias); 24 Jun 2016 22:23:31 -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 63992 invoked by uid 89); 24 Jun 2016 22:23:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= 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; Fri, 24 Jun 2016 22:23:20 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C7E647EBAC; Fri, 24 Jun 2016 22:23:18 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5OMNGe9006026; Fri, 24 Jun 2016 18:23:17 -0400 Subject: Re: [PATCH v2] Optimize memory_xfer_partial for remote To: Don Breazeal , gdb-patches@sourceware.org, qiyaoltc@gmail.com References: <1466803274-62026-1-git-send-email-donb@codesourcery.com> From: Pedro Alves Message-ID: <0e16a8d3-0fc6-2b1f-c5aa-799ec91d4e0d@redhat.com> Date: Fri, 24 Jun 2016 22:23:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <1466803274-62026-1-git-send-email-donb@codesourcery.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-06/txt/msg00412.txt.bz2 On 06/24/2016 10:21 PM, Don Breazeal wrote: > > and with commit hash: 67c059c29e1fb0cdeacdd2005f955514d8d1fb34 > Write: ... with commit 67c059c29e1f ("Improve performance of large restore commands") ... so the reader has a clue what the commit is about without having to check. > gdb/ChangeLog: > 2016-06-24 Don Breazeal > > * remote.c (remote_get_memory_xfer_limit): New function. > * target-delegates.c (delegate_get_memory_xfer_limit, > debug_get_memory_xfer_limit, install_delegators, > install_dummy_methods, init_debug_target): New functions > and target_ops initialization from regenerating the file. The standard practice is to just say: * target-delegates.c: Regenerate. > * target.c (default_get_memory_xfer_limit): New function and > forward declaration. > (memory_xfer_partial): Call target_ops.to_get_memory_xfer_limit. > * target.h (struct target_ops): New > member. Space between ")<". > > diff --git a/gdb/remote.c b/gdb/remote.c > index 501f3c6..03c7ab7 100644 > --- a/gdb/remote.c > +++ b/gdb/remote.c > @@ -10160,6 +10160,12 @@ remote_xfer_partial (struct target_ops *ops, enum target_object object, > return TARGET_XFER_OK; > } > > +static ULONGEST > +remote_get_memory_xfer_limit (struct target_ops *ops) Intro comment, something like "Implementation of ... method.". > > +/* The default implementation for the to_get_memory_xfer_limit method. > + The hard-coded limit here was determined to be a reasonable default > + that eliminated exponential slowdown on very large transfers without > + unduly compromising performance on smaller transfers. */ Where's this coming from? Is this new experimentation you did, or are you talking about Anton's patch? > @@ -1301,8 +1314,9 @@ memory_xfer_partial (struct target_ops *ops, enum target_object object, > by memory_xfer_partial_1. We will continually malloc > and free a copy of the entire write request for breakpoint > shadow handling even though we only end up writing a small > - subset of it. Cap writes to 4KB to mitigate this. */ > - len = min (4096, len); > + subset of it. Cap writes to a limit specified by the target > + to mitigate this. */ > + len = min (ops->to_get_memory_xfer_limit (ops), len); > Does this still work if remote is not the top-most target? E.g., what happens if you do "record" to push a record_statum target on top? Do we get the 4KB default limit, or the remote limit? Thanks, Pedro Alves