It's a valid senario, the issue is that we've never been that good about updating firstWordTime and finishTime at every device. Really the caches should all be setting it.
Ali On Jul 7, 2012, at 5:17 PM, Uri Wiener wrote: > Hi, > > I'm having a problem with systems containing stacked caches with no buses > in-between and would appreciate some feedback. > > The system I use contains cpu -> l1c -> l2c -> membus -> physmem. Hence no > bus between l1c and l2c. > The cpu issues a write request, translated to a readEx by l1c, sent to l2c, > through the membus to physmem and back. > > Possible problem: > responses going directly from cache to cache don't update the packet's > finishTime and firstWordTime. > > Scenario of the problem / suspicious behavior: > 1. cpu creates a new packet (packet #1) for the write request, passes it to > l1c, causes a write miss. Packet is added to the MSHR target list. > 2. during access to l1c, a readEx packet is created (in getTimingPacket) > - packet #2. It is passed to l2c (timingAccess), and added to l2c's MSHR > targets list. > 3. l2c creates a new packet (in getTimingPacket) - packet #3, and passes it > to the membus, then to physmem and back. > 4. The membus updates packet #3's finishTime and firstWordTime, and passes > it to l2c. > 5. l2c handles the response, frees packet #3, fetches the target from the > MHSR target list (packet #2) and and calls cpuSidePort->respond (to l1c), > scheduling is based on pkt->finishTime. > 6. l1c gets the packet (#2) from l2c's mshr target list. >>>> The problem is here<<<: l2c handles the response, and sends it to the > cpu based on packet #2's pkt->finishTime, which was never initialized. > 7. (just for the sake of completeness) l1c frees packet #2, sends the > target packet (#1) from its mhsr target list to the cpu based on an > invalid completion_time. > The cpu receives the response at this random time, and finishes the > transaction. > > Hence the problem I'm suspecting is a cache getting a response from a > lower-level cache, without updating its current target's finishTime and > firstWordTime. > Probably something that might be missing in handleResponse > (src/mem/cache/cache_impl.hh). > > > Is this a valid structure and scenario? Could someone have a look and tell > me if this makes sense? > > Thanks, > > Uri > _______________________________________________ > 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
