This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Known problems with dcache?
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 10 Jan 2003 17:25:51 -0500
- Subject: Re: Known problems with dcache?
- References: <3E1F46CB.9060104@redhat.com>
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