Hi Tim, I'm not sure whether this is really a bug. 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.
Are you still testing this with MOESI_hammer? 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? Thanks! Joel On Mon, Jun 22, 2015 at 2:15 PM, Timothy M Jones <[email protected] > wrote: > Hi All, > > On 19/06/2015 09:22, Timothy M Jones wrote: > >> I think my first step will be to verify that the blocks in each of the >> caches at the point the checkpoint is taken is the same as after the >> checkpoint has been restored. >> > > I have tracked down the problem to a particular line in one of the L1 > caches. There's a fairly simple (and obvious) check on each block's access > permissions to determine what request to make in the trace to restore state: > > 1) Read-only and instruction cache => Instruction fetch request > 2) Read-only otherwise => Load request > 3) Read-write permissions => Store request > > However, I've got a block with read-only permission that still manages to > contain dirty data! Could anyone tell me how this can happen? > > 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 > -- Joel Hestness PhD Candidate, Computer Architecture Dept. of Computer Science, University of Wisconsin - Madison http://pages.cs.wisc.edu/~hestness/ _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
