Messages in this thread | | | Date | Thu, 28 Jan 1999 18:51:49 +1100 | From | Richard Gooch <> | Subject | Variability in cache access times |
| |
Hi, all. Recently I queried whether TLB refills were causing variabilities in some volume rendering benchmarks I was doing (thanks to Ingo for his response). Upon further investigation, it seems the problems are due to variability in L2 access times, and in particular, variability in the number of L2 cache misses. I'm using the performance monitoring counters on the PPro to count cache hits and misses.
The test programme I'm using clears a block of memory on the stack, and then proceeds to read it (linearly) many times (roughly 0.5 s of work), timing the whole read operation. In my tests I chose 128 kBytes for the block size, as that should fit nicely into the L2 cache on the PPro.
From one invocation to the next, I can easily go from 322 million bytes/sec bandwidth down to 177 million bytes/sec. In the former case, the number of external memory bus accesses is quite small. In the latter case, the number of bus accesses is hundreds of times higher. Clearly, in the second case, the L2 cache is missed many times.
In the former case (high bandwidth), the physical pages the buffer lies in is spread across these blocks (where each block is 1 MB of RAM): 26 194 199 170 7 5 177.
In the latter case (low bandwidth), the blocks the buffer resides in are: 199 194 26 186 204.
These are just two invocations of the test programme, but they are resonably representative of the kind of variabilities in the bandwidth result I'm seeing. The locations of the physical pages tends to jump around a bit. I've not collected statistics on these yet (not sure if that will reveal anything significant, besides, it's tedious).
The machine I'm running this on is a dual PPro 180 (256 kByte L2 caches). I'm running a UP 2.2.0 kernel. The test programme is running with RT priority (I don't want to give the X server a chance to pollute the cache). The test programme is available on request.
I'd welcome any insights into this problem or suggestions for further testing.
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |