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 5988 invoked from network); 10 Jan 2003 22:25:37 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 10 Jan 2003 22:25:37 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18X9TQ-0005N9-00; Fri, 10 Jan 2003 18:26:04 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18X7b5-0002fc-00; Fri, 10 Jan 2003 17:25:51 -0500 Date: Fri, 10 Jan 2003 22:25:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: Known problems with dcache? Message-ID: <20030110222551.GA10139@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <3E1F46CB.9060104@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E1F46CB.9060104@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00177.txt.bz2 On Fri, Jan 10, 2003 at 05:18:51PM -0500, Andrew Cagney wrote: > Hello, > > In a recent discussion there was mention made of dcache. How, when > enabled, it could make things? Are there any more details. > > The only problem I know with dcache is with the way it turns a single > byte read into a 32 byte read. I think it should instead behave like a > register fetch: That depends how it's configured... you can set it up to do smaller reads. Err, I thought you could. Maybe I was dreaming? > - request exactly the specified amount > > - allow the target to supply additional data > > ex: ask for a byte, get back a page. > > I even think that, with that fix, the dcache could be enabled by default > - it couldn't accidently do things like read beyond the end of memory > and in the process trash something for instance. > > Andrew > > PS: Thinking about it, given ptrace's 4 byte straw, 32 bytes ~= 8 ptrace > calls and that could be enough to make a difference? We don't use the straw on some targets now; Linux (need to get back to that patch and turn it on always!), *BSD. 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. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer