- 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,
-
- eg, x/200x 0
-
- caching | no yes
- ----------------------------
- first time | 4 sec 2 sec improvement due to chunking
- second time | 4 sec 0 sec improvement due to caching
-
- The cache structure is unusual, we keep a number of cache blocks
- (DCACHE_SIZE) and each one caches a LINE_SIZEed area of memory.
- Within each line we remember the address of the line (always a
- multiple of the LINE_SIZE) and a vector of bytes over the range.
- There's another vector which contains the state of the bytes.
+ bundles up the requests into LINE_SIZE chunks, reducing overhead
+ significantly. This is most useful when accessing a large amount
+ of data, such as when performing a backtrace.
+
+ The cache is a splay tree along with a linked list for replacement.
+ Each block caches a LINE_SIZE area of memory. Within each line we
+ remember the address of the line (which must be a multiple of
+ LINE_SIZE) and the actual data block.
+
+ Lines are only allocated as needed, so DCACHE_SIZE really specifies the
+ *maximum* number of lines in the cache.
+
+ At present, the cache is write-through rather than writeback: as soon
+ as data is written to the cache, it is also immediately written to
+ the target. Therefore, cache lines are never "dirty". Whether a given
+ line is valid or not depends on where it is stored in the dcache_struct;
+ there is no per-block valid flag. */
+
+/* NOTE: Interaction of dcache and memory region attributes
+
+ As there is no requirement that memory region attributes be aligned
+ to or be a multiple of the dcache page size, dcache_read_line() and
+ dcache_write_line() must break up the page by memory region. If a
+ chunk does not have the cache attribute set, an invalid memory type
+ is set, etc., then the chunk is skipped. Those chunks are handled
+ in target_xfer_memory() (or target_xfer_memory_partial()).
+
+ This doesn't occur very often. The most common occurance is when
+ the last bit of the .text segment and the first bit of the .data
+ segment fall within the same dcache page with a ro/cacheable memory
+ region defined for the .text segment and a rw/non-cacheable memory
+ region defined for the .data segment. */
+
+/* The maximum number of lines stored. The total size of the cache is
+ equal to DCACHE_SIZE times LINE_SIZE. */
+#define DCACHE_DEFAULT_SIZE 4096
+static unsigned dcache_size = DCACHE_DEFAULT_SIZE;
+
+/* The default size of a cache line. Smaller values reduce the time taken to
+ read a single byte and make the cache more granular, but increase
+ overhead and reduce the effectiveness of the cache as a prefetcher. */
+#define DCACHE_DEFAULT_LINE_SIZE 64
+static unsigned dcache_line_size = DCACHE_DEFAULT_LINE_SIZE;