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/