Known problems with dcache?

Known problems with dcache?

[Andrew Cagney]

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:

- 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?

Re: Known problems with dcache?

[Daniel Jacobowitz]

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

Re: Known problems with dcache?

[Andrew Cagney]

> 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.

Andrew

Re: Known problems with dcache?

[Daniel Jacobowitz]

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.  Might be worth trying it again, with larger
lines, now.  Not sure.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Known problems with dcache?

[Andrew Cagney]

> 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.

>   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.

Andrew

Re: Known problems with dcache?

[Daniel Jacobowitz]

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

Re: Known problems with dcache?

[Andrew Cagney]

>> 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.

It definitly affects things.  Both codestream and dcache are chewing cpu 
cycles trying to cache instruction reads.  A valid comparison would at 
least involve no dcache/codestream.

Andrew

Re: Known problems with dcache?

[Daniel Jacobowitz]

On Fri, Jan 10, 2003 at 06:15:55PM -0500, Andrew Cagney wrote:
> 
> >>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.
> 
> It definitly affects things.  Both codestream and dcache are chewing cpu 
> cycles trying to cache instruction reads.  A valid comparison would at 
> least involve no dcache/codestream.

Sure; but it's overwhelmed by the LinuxThreads I/O, which doesn't touch
codestream at all; instruction reads weren't even a measurable time
last time I did this.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Known problems with dcache?

[Andrew Cagney]

> On Fri, Jan 10, 2003 at 06:15:55PM -0500, Andrew Cagney wrote:
> 
>> 
> 
>> >>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.
> 
>> 
>> It definitly affects things.  Both codestream and dcache are chewing cpu 
>> cycles trying to cache instruction reads.  A valid comparison would at 
>> least involve no dcache/codestream.
> 
> 
> Sure; but it's overwhelmed by the LinuxThreads I/O, which doesn't touch
> codestream at all; instruction reads weren't even a measurable time
> last time I did this.

Clearly another factor to preclude when establishing the baseline.  The 
base comparison is dcache vs codestream vs nothing, a potential 
secondary effect is with the thread code.

Andrew