From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8499 invoked by alias); 25 Jul 2013 17:30:20 -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 8490 invoked by uid 89); 25 Jul 2013 17:30:20 -0000 X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_20,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RDNS_NONE,TW_CP autolearn=no version=3.3.1 Received: from Unknown (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 25 Jul 2013 17:30:19 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1V2PMh-0000RX-Ia from Luis_Gustavo@mentor.com ; Thu, 25 Jul 2013 10:30:11 -0700 Received: from NA1-MAIL.mgc.mentorg.com ([147.34.98.181]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Jul 2013 10:30:11 -0700 Received: from [172.30.2.5] ([172.30.2.5]) by NA1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jul 2013 10:30:10 -0700 Message-ID: <51F1609F.2030803@codesourcery.com> Date: Thu, 25 Jul 2013 17:30:00 -0000 From: Luis Machado Reply-To: lgustavo@codesourcery.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Anton Blanchard CC: gdb-patches@sourceware.org Subject: Re: [PATCH] Improve performance of large restore commands References: <20130725220858.58184193@kryten> In-Reply-To: <20130725220858.58184193@kryten> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-07/txt/msg00625.txt.bz2 On 07/25/2013 09:08 AM, Anton Blanchard wrote: > > I noticed a large (100MB) restore took hours to complete. The problem > is target_xfer_partial repeatedly mallocs and memcpys the entire > 100MB buffer only to find a small portion of it is actually written. > > We already cap reads to 4K, so do that for writes. The testcase that > originally took hours now takes 50 seconds. > > -- > > 2013-07-25 Anton Blanchard > > * target.c (target_write_with_progress): Cap write to 4K > > Index: b/gdb/target.c > =================================================================== > --- a/gdb/target.c > +++ b/gdb/target.c > @@ -2287,9 +2287,11 @@ target_write_with_progress (struct targe > > while (xfered < len) > { > + /* Cap the write to 4K */ > + int to_transfer = min(4096, len - xfered); > LONGEST xfer = target_write_partial (ops, object, annex, > (gdb_byte *) buf + xfered, > - offset + xfered, len - xfered); > + offset + xfered, to_transfer); > > if (xfer == 0) > return xfered; > > Looks good to me. Did you consider extending the comment a little to explain what will happen if we don't cap the write to 4K? Thanks, Luis