If you look at the attached annotated trace you can see that a cache block was
written to, was dirty and then the dirty flag goes away at some point. I traced
it down to this code in the cache:
// special considerations if we're owner:
if (!deferred_response) {
// if we are responding immediately and can
// signal that we're transferring ownership
// along with exclusivity, do so
pkt->assertMemInhibit();
blk->status &= ~BlkDirty;What seems to be happening is that the o3 cpu's fetch stage is grabbing an entire block at a time, which makes the L1I cache believe it can provide ownership to the cache above it (there isn't one) during the fetch. The fetch stage doesn't do anything special when it's provided ownership of the block, nor should it ever be provided ownership, so the information gets lost. I'm actually very surprised we haven't hit this before. Anyway, the question is how to fix it. I can think of two solutions and I'm going to implement (1) if no one has a better suggestion. 1) Add a parameter indicating that the cache is at the top level and disable this stuff when the parameter is set 2) Not do anything special (remove the optimization above, which make the protocol less performant) 3) ???? Ali
trace.o3.err.3
Description: Binary data
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
