On Tue, 30 Aug 2011 11:06:55 -0700, Steve Reinhardt <[email protected]>
wrote:
I like to think I'm good at this, but I'm going to have a hard time
identifying the bug with that short of a trace ;-).
On Tue, Aug 30, 2011 at 9:39 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:
496726046000: system.cpu.dcache: ReadReq 8cabe0 miss
_______________________________________________
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
This is the second time this has happened... try #2:
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
