From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23481 invoked by alias); 20 Jul 2011 16:35:33 -0000 Received: (qmail 23226 invoked by uid 22791); 20 Jul 2011 16:35:30 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 Jul 2011 16:35:16 +0000 Received: (qmail 13296 invoked from network); 20 Jul 2011 16:35:15 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 20 Jul 2011 16:35:15 -0000 From: Pedro Alves To: Paul Pluzhnikov Subject: Re: [RFC][patch] Avoid repeated calls to solib_add on initial attach. Date: Wed, 20 Jul 2011 16:56:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; x86_64; ; ) Cc: gdb-patches@sourceware.org, Luis Machado References: <20110715205209.8B3B3190BC2@elbrus2.mtv.corp.google.com> <201107201537.18159.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107201735.13150.pedro@codesourcery.com> X-IsSubscribed: yes 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 X-SW-Source: 2011-07/txt/msg00548.txt.bz2 On Wednesday 20 July 2011 17:04:11, Paul Pluzhnikov wrote: > On Wed, Jul 20, 2011 at 7:37 AM, Pedro Alves wrote: > > On Friday 15 July 2011 21:52:09, Paul Pluzhnikov wrote: > >> Greetings, > >> > >> Following up on my earlier "slow on high-latency links" message: > >> http://sourceware.org/ml/gdb-patches/2011-07/msg00391.html ... > >> > >> Attached patch avoids calling solib_add twice when initially attaching > >> inferior. > >> > >> I am not entirely happy about this patch, but don't have a better idea > >> for a fix, and do want to avoid repeated rescans of the shared library list. > > > > Me neigher, apart from doing as the comment says: > > > >> /* Sometimes the platform-specific hook loads initial shared > >> libraries, and sometimes it doesn't. If it doesn't FROM_TTY will be > >> incorrectly 0 but such solib targets should be fixed anyway. If we > >> made all the inferior hook methods consistent, this call could be > >> removed. Call it only after the solib target has been initialized by > >> solib_create_inferior_hook. */ > > > > Or, making retrieving the dso list cheap enough to not care about the > > multiple calls. By e.g., caching more things, and making > > target_read_string not super dumb (as you've yourself proposed). > > I think DSO list with 4K entries and 200ms packet response time is not > going to ever become cheap enough. Yeah. > Fixing all inferior hook methods to be consistent and always load > initial DSO list sounds promising, but has the practical problem: I don't > have access to many systems. I'll check what I can do there ... I'm not certain of the amount of work here. I'm okay with your approach as fallback (you should make the counter unsigned to avoid undefined signed overflow). > > > Can you give a try on the attached patches and see how much > > a difference they make for you? > > Thanks, I'll try them. > > > Patch 2 has the most dramatic affect; > > Yes, I've already tried equivalent patch (except I set the default > size to 128), and (as expected) it did make a big difference. > > Going back to the new packet proposal to speed up target_read_string; > do you have any additional comments on > > qStr {addr},{maxlen},{terminator} > > format? Should {terminator} be optional? Should I avoid it altogether > (it doesn't solve any current problem, so perhaps it's over-design) ? We considered a packet like this too, but decided that bumping target_read_string first and seeing if anything breaks would be better. Haven't heard back of any breakage or slowdown so far. I propose we do the same upstream. -- Pedro Alves