From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26746 invoked by alias); 22 Nov 2002 05:29:45 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 26739 invoked from network); 22 Nov 2002 05:29:44 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 22 Nov 2002 05:29:44 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18F8GI-0000Pi-00; Fri, 22 Nov 2002 01:30:02 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18F6No-00072r-00; Fri, 22 Nov 2002 00:29:40 -0500 Date: Thu, 21 Nov 2002 21:29:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: PATCH/RFC: Bring lin-lwp performance back to the real world Message-ID: <20021122052939.GA26668@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <20021122041123.GA21389@nevyn.them.org> <3DDDB7B5.2070809@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DDDB7B5.2070809@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-11/txt/msg00537.txt.bz2 On Thu, Nov 21, 2002 at 11:51:01PM -0500, Andrew Cagney wrote: > > - It's such a wonderful bandaid that a lot of the badly needed > > cleanups may lose momentum. > > ``Don't you worry about that'' :-) > > A back of envelope calculation shows: > > >Plucking a ``random'' memory location out of thin air: > > > >cagney@torrens$ grep 0x40040ea0 gdb.strace | grep ptrace | wc -l > > 7038 > > For <160 stops, GDB fetched a thread-db buffer 7000 times. So, GDB is > fetching an identical buffer 7000/160 ~= 50 times for every stop! > > >cagney@torrens$ expr 7038 \* 250 > >1759500 > > 250? I happen to know that the buffer is ~1000 bytes long which gives > us 250 (1000/sizeof(long) ptrace() calls for every buffer transfer. > > The patch addresses the second problem, but not the first. While it > releaves a bit of steam, there is still plenty of oportunity to further > ramp up the performance by several more orders of magnitude. > > (BTW, this sort of brain-deadness on the part of GDB explains why other > minor performance tweeks had zero benefit :-) > > ---- > > Note that the other /proc trickery is in linux-proc.c. Should this be > there? Hrm, possibly. I needed to create linux-nat.c anyway (I'll need it for some things that are definitely not /proc related) but I could be persuaded either way on linux_proc_xfer_memory. It's not focused on the "proc" bit as much as the "xfer" bit, but it's definitely using /proc. If you prefer I'll move it, and save linux-nat.c for another patch. Thanks for the pointer to pread. I don't know how far back it's available... looks like 1997-09-30 in glibc. Could just assume pread64 and force -D_LARGEFILE64_SOURCE, I think - it's been there in all of glibc2 and libc4/libc5 are pretty darned niche now. Could autoconf for it instead, easy enough... I think I'll update the patch to autoconf check for pread64 with appropriate compilation flags, and fall back to 32-bit lseek/read. I'll repost it after I decide what to do about linux-proc vs linux-nat, and any other comments come in (i.e. not tonight!). -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer