This is the mail archive of the 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]


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.


J.T. Conklin
RedBack Networks

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