From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Received: (qmail 28349 invoked from network); 10 Jan 2003 23:04:21 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 10 Jan 2003 23:04:21 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18XA4v-0005Rp-00; Fri, 10 Jan 2003 19:04:49 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18X8CZ-0008Ov-00; Fri, 10 Jan 2003 18:04:35 -0500 Date: Fri, 10 Jan 2003 23:04:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: Known problems with dcache? Message-ID: <20030110230435.GA32277@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <3E1F46CB.9060104@redhat.com> <20030110222551.GA10139@nevyn.them.org> <3E1F4ACC.7080504@redhat.com> <20030110223834.GA10769@nevyn.them.org> <3E1F4F74.5020704@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E1F4F74.5020704@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00183.txt.bz2 On Fri, Jan 10, 2003 at 05:55:48PM -0500, Andrew Cagney wrote: > >On Fri, Jan 10, 2003 at 05:35:56PM -0500, Andrew Cagney wrote: > > > >> > > > >>>We don't use the straw on some targets now; Linux (need to get back to > >>>that patch and turn it on always!), *BSD. > > > >> > >>Right so that 32 byte read is now cheap. > >> > > > >>>The dcache needs some serious work if you want it to be always on. > >>>Last time I tested it it caused an actual slowdown. Basically, it's > >>>too small to be useful. > >>> > >>>#define DCACHE_SIZE 64 > >>>#define LINE_SIZE_POWER (5) > >>> > >>>So it never stores more than 2K. LinuxThreads _overwhelms_ that, by a > >>>downright boggling amount. > > > >> > >>You wouldn't know why it caused a slow down? Th 32 byte read should now > >>be cheaper. > > > > > >This was before the 32-byte-read support. So we read lines in, did > >more computation than before, and overwrote them in the cache; exactly > >the same I/O, more CPU. > > Well, possibly more I/O. And, I think, the I/O / context switch / ... > is the expensive part. Probably, yes. > > Might be worth trying it again, with larger > >lines, now. Not sure. > > Was it on an i386? If it was, the other other cache would easily skew > any results. Other other cache? Codestream doesn't affect this so I don't know what you mean. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer