dcache

dcache

[J.T. Conklin]

The dcache_flush() routine throws away its contents.  I don't know
about you guys, but to me flushing a cache implies writing out the
contents, is there any objection to renaming this function to some-
thing like dcache_invalidate()?  The dcache_writeback() function is
a real cache flush, but writeback is just as descriptive.  I see no
reason to rename it to dcache_flush().

The following comment within dcache.c:

    In general the dcache speeds up performance, some speed improvement
    comes from the actual caching mechanism, but the major gain is in the
    reduction of the remote protocol overhead; instead of reading or
    writing a large area of memory in 4 byte requests, the cache bundles
    up the requests into 32 byte (actually LINE_SIZE) chunks.  Reducing
    the overhead to an eighth of what it was.  This is very obvious when
    displaying a large amount of data,

Implies that GDB writes reads and memory in small chunks instead of
larger chunks, and the dcache speeds this up by coalescing multiple
small transactions into larger ones.  Does anyone know the truth of
this implication, especially for writes?

I ask because the current implementation is a writethrough cache ---
small writes aren't going to be combined.  I suspect in most cases, if
target memory is cached at all, this is the desired behavior.  (e.g. A
user setting a global flag probably wants that change to be reflected
immediately, so that another thread of execution can act upon it).  

Are there any circumstances where a writeback cache would be useful?
While I'm fiddling around with dcache, it would not be difficult to
add.  Every place there's a dcache_flush() in target code would be
replaced with something like dcache_writebackinvalidate(), and the
dcache_xfer_memory could avoid writing the data if the memory region
was configured for a writeback behavior.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: dcache

[Andrew Cagney]

"J.T. Conklin" wrote:
> 
> The dcache_flush() routine throws away its contents.  I don't know
> about you guys, but to me flushing a cache implies writing out the
> contents, is there any objection to renaming this function to some-
> thing like dcache_invalidate()?  The dcache_writeback() function is
> a real cache flush, but writeback is just as descriptive.  I see no
> reason to rename it to dcache_flush().

Yes, long ago I thought I knew what a flush function did.  Since reading
GDB's code I've become very confused :-)
serial.c has exactly the same problem.  It's ``drain()'' function
implements flush().  Dig dig, hmm, serial's flush dates back to
1993/06/30 while dcache is around that same period (different authors
though :-).

> Implies that GDB writes reads and memory in small chunks instead of
> larger chunks, and the dcache speeds this up by coalescing multiple
> small transactions into larger ones.  Does anyone know the truth of
> this implication, especially for writes?

Ignoring the dcache() gdb definitly likes to perform small writes (1-4
bytes).  The easiest case to monitor would be an inferior function call.

> I ask because the current implementation is a writethrough cache ---
> small writes aren't going to be combined.  I suspect in most cases, if
> target memory is cached at all, this is the desired behavior.  (e.g. A
> user setting a global flag probably wants that change to be reflected
> immediately, so that another thread of execution can act upon it).

The behavour should be the same as with registers.  As far as the user
can see, operations are write through.
However, internally, gdb would benefit from a write back mechanism when
implementing inferior function calls.

> Are there any circumstances where a writeback cache would be useful?
> While I'm fiddling around with dcache, it would not be difficult to
> add.  Every place there's a dcache_flush() in target code would be
> replaced with something like dcache_writebackinvalidate(), and the
> dcache_xfer_memory could avoid writing the data if the memory region
> was configured for a writeback behavior.

The test call-ar-st.exp would benefit significantly!

	Andrew