I suggest you also add an assert in the fetch unit if it receives a block with
ownership, if that is easy to do.
Sent from my iPhone
On Feb 20, 2011, at 12:05 PM, Ali Saidi <sa...@umich.edu> wrote:
> 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>
> _______________________________________________
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
