This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Known problems with dcache?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]