This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Known problems with dcache?
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