From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63755 invoked by alias); 30 Jun 2016 17:06:40 -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 63746 invoked by uid 89); 30 Jun 2016 17:06:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=scenario, reevaluate, Don, transfers 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; Thu, 30 Jun 2016 17:06:39 +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 DD295C00F1C5; Thu, 30 Jun 2016 17:06:37 +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 u5UH6ZxH029109; Thu, 30 Jun 2016 13:06:35 -0400 Subject: Re: [PATCH v2] Optimize memory_xfer_partial for remote To: Don Breazeal , gdb-patches@sourceware.org, qiyaoltc@gmail.com References: <1467058970-62136-1-git-send-email-donb@codesourcery.com> From: Pedro Alves Message-ID: <6e4787d9-f6d5-641e-ffd5-1dd255806b3b@redhat.com> Date: Thu, 30 Jun 2016 17:06: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: <1467058970-62136-1-git-send-email-donb@codesourcery.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-06/txt/msg00556.txt.bz2 On 06/27/2016 09:22 PM, Don Breazeal wrote: >>> +/* 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? > > Both. I did some experimentation to verify that things were significantly > slower without any memory transfer limit, which they were, although I never > reproduced the extreme scenario Anton had reported. Presumably the > performance differences were due to hardware and environment differences. > Regarding the comment, I thought some explanation of the hard-coded number > was appropriate. Is there a better or more preferable way to do this, e.g. > refer to the commit hash, or does it just seem superfluous? OK, you didn't mention this experimentation, which left me wondering. Particularly, the mention of "exponential" is what most made me pause, as it's a qualifier not mentioned elsewhere. I guess my main problem with the comment is that by reading it in isolation, one has no clue of how what would cause the slowdown (normally transferring more at a time is faster!), and thus how to reevaluate the default in the future. How about extending to something like: /* 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. This slowdown is mostly caused by memory writing routines doing unnecessary work upfront when large requests end up usually only partially satisfied. See memory_xfer_partial's handling of breakpoint shadows. */ Actually, I was going to approve this with that change, but another another thought crossed my mind, sorry... I assume you did this experimentation with remote targets? But this default will never be used with those, so that experimentation is meaningless for native targets? Actually, the whole capping is probably pointless with native targets, since there's really no marshalling and thus no limit. That'd suggest making the target method return "-1" or some such to indicate there's no limit. WDTY? Thanks, Pedro Alves