Hi Joel, On 22/06/2015 20:35, Joel Hestness wrote:
I'm not sure whether this is really a bug.
No, I'm sure that this isn't the bug. The problem is that when the line is restored it isn't restored to the same state (my guess so far is that it isn't consistent with memory and because this dirty bit isn't preserved in the checkpoint / ruby trace, it causes the wrong data to be used somewhere later down the line.
Dirty cache lines could be shared in a read-only state among caches. Whether to allow data in caches to differ from memory (i.e. dirty bit set) is a choice by a directory of a protocol. It could write a line back to memory to clean it, or allow shared (read-only) copies that are the same, but dirty among caches. I'm not sure whether the MOESI_hammer directory allows this, but it can be a possibility.
OK, thanks for the explanation.
Are you still testing this with MOESI_hammer?
Yes, I am.
Also, I'm not sure what code you're referring to that checks the access permissions and dirty bits (during cache warm-up?). Can you point us to that code?
Yeah, the problem is that it doesn't check the dirty bits, just the access permissions. It's in src/mem/ruby/structures/CacheMemory.cc:326, function recordCacheContents()
Cheers Tim -- Timothy M. Jones http://www.cl.cam.ac.uk/~tmj32/ _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
