It seems odd, but since neither one is dirty, it's not necessarily a problem. Basically no request can come to the L2 without snooping the L1 first (if it comes in from the CPU side, the L1/L2 bus will snoop the L1 before the request hits the L2; if it comes in from the mem side, the upward "express" snoop in the L2's handleSnoop() call will check the L1 first, as long as forwardSnoops is set on the L2). So the exclusive flag on the L2 just means that none of the L2's peers (i.e., other L2s) have a copy, not that no other cache in the system has a copy.
There may be a hole in my analysis that means that it is a problem, but I'm curious what that would be... which is why I asked where things tangibly went wrong (e.g., someone reading a stale value), since I'm curious how this situation could lead to that. Steve On Thu, Sep 8, 2011 at 8:38 PM, Ali Saidi <[email protected]> wrote: > What I thought was wrong was that blocks that were marked valid, writeable > and readable appear to exist both in the l1 and l2. When the L1 got the > block from the L2 the L2 should have sent it shared or invalidated it's > copy. Ultimately, the l1 has a valid writable copy of the block that it > writes back to the L2 and it gets a hit on the writeback. If it has write > permission should that ever happen? > > Ali > > > On Sep 8, 2011, at 6:05 PM, Steve Reinhardt wrote: > > > Hi Ali, > > > > I realize this was a while ago, but can you elaborate on the actual error > > you ran into in this circumstance? I agree that the trace below may seem > > superficially odd to the casual observer, but it's not clear to me how > this > > behavior leads to a wrong answer; it looks to me like at the end of the > > trace the modified block from the L1 has been successfully written back > to > > the L2, where (assuming the L2 block is marked as dirty) it should be > > residing happily until it's either written back or accessed again. > > > > Thanks, > > > > Steve > > > > On Tue, Aug 30, 2011 at 11:26 AM, Ali Saidi <[email protected]> wrote: > > > >> > >> Hi Everyone, > >> > >> > >> > >> I've run into yet another issue with an L2 prefetcher doing something > >> weird. I'm hoping that someone (mostly Steve) could tell me what is > supposed > >> to happen in this case to fix it. Obligatory trace below: > >> > >> <Prefetcher inserts address 0x8cabc0 into prefetch queue> > >> > >> 496726046000: system.cpu.dcache: ReadReq 8cabe0 miss <--- Miss from > CPU > >> for address > >> > >> 496726048000: system.tol2bus: recvTiming: src 4 dst -1 ReadReq 0x8cabc0 > >> <--- Address going to L2 > >> > >> 496726048000: system.l2: ReadReq 8cabc0 miss <--- L2 sees the miss from > >> the dcache above > >> > >> 496726048000: system.l2-pf: hit: PC 32f0 blk_addr 8cabc0 stride 1856 > >> (change), conf 0 <--- the prefetcher found one, yay! > >> > >> 496726060000: system.membus: recvTiming: src 7 dst -1 ReadReq 0x8cabc0 > >> <--- This is the prefetch leaving the L2 > >> > >> 496726060000: system.physmem: Read of size 64 on address 0x8cabc0 > >> > >> 496726114000: system.membus: recvTiming: src 6 dst 7 ReadResp 0x8cabc0 > >> <--- Data returning from memory to L2 > >> > >> 496726114000: system.l2: Handling response to 8cabc0 > >> > >> 496726114000: system.l2: Block for addr 8cabc0 being updated in Cache > >> > >> 496726114000: system.l2: Block addr 8cabc0 moving from state 0 to 7 > >> <---- Block marked as valid+readable+writeable in L2 > >> > >> 496726133892: system.tol2bus: recvTiming: src 0 dst 4 ReadResp 0x8cabc0 > >> <---- Block sent to cache above > >> > >> 496726133892: system.cpu.dcache: Handling response to 8cabc0 > >> > >> 496726133892: system.cpu.dcache: Block for addr 8cabc0 being updated in > >> Cache > >> > >> 496726133892: system.cpu.dcache: replacement: replacing 556bc0 with > 8cabc0: > >> clean > >> > >> 496726133892: system.cpu.dcache: Block addr 8cabc0 moving from state 0 > to 7 > >> <--- Also seems to have been allocated as valid+readable+writeable in > >> L1!!! > >> > >> 496741134000: system.cpu.dcache: replacement: replacing 8cabc0 with > 536bc0: > >> writeback > >> > >> 496741136000: system.coretol2buses: recvTiming: src 4 dst -1 Writeback > >> 0x8cabc0 BUSY > >> > >> 496741139001: system.coretol2buses: recvTiming: src 4 dst -1 Writeback > >> 0x8cabc0 BUSY > >> > >> 496741140000: system.coretol2buses: recvTiming: src 4 dst -1 Writeback > >> 0x8cabc0 > >> > >> 496741140000: system.l2: Writeback 8cabc0 hit <-- Should it ever be > valid > >> to get a hit on a writeback? > >> > >> > >> > >> So.. The question is now, what went horribly wrong and how should it be > >> fixed? I can think of a couple of possibilities, but it seems like what > is > >> happening is that the mshr for the PF isn't marked as InService until it > >> issues, but the read request from the dcache comes in right before that > >> happens. Since the MSHR isn't in service and we short circuit some of > the > >> mshr handling things that would mark the mshr so either a copy doesn't > get > >> put in the L2 or both are shared. Thoughts? > >> > >> > >> > >> Ali > >> > >> > >> > >> ______________________________**_________________ > >> gem5-dev mailing list > >> [email protected] > >> http://m5sim.org/mailman/**listinfo/gem5-dev< > http://m5sim.org/mailman/listinfo/gem5-dev> > >> > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
