-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2784/#review6137
-----------------------------------------------------------


While Andreas Hansson should have a better understanding of whether this 
correct or not,
the explanation does not read like a live lock to me.  It just seems that the 
second store
is being delayed.  Livelock means that some superficial work is going on even 
though actual
progress is not being made.

- Nilay Vaish


On May 11, 2015, 10:19 p.m., Tony Gutierrez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2784/
> -----------------------------------------------------------
> 
> (Updated May 11, 2015, 10:19 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> -------
> 
> Changeset 10841:b015addd7b9d
> ---------------------------
> mem: MSHR livelock bug fix
> 
> This patch was created by Bihn Pham during his internship at AMD.
> 
> This bug fix prevents a case in which a prefetcher uses up all remaining MSHR
> entries before demand requests get a chance to, causing a livelock.
> This happens because events scheduled at curTick() + 1 are evaluated in the
> next cycle, not in the current cycle.
> 
> A specific case that caused this livelock situation is the following:
> There are back-to-back stores and the second store cannot be sent to the cache
> until the first store receives an ACK. When the ACK is scheduled at curTick() 
> +
> 1, meaning that the ACK is to be sent in the next cycle, there is an open MSHR
> entry in the current cycle. A prefetcher grabs the entry by issuing a prefetch
> request in the current cycle before the second store gets a chance to issue in
> the next cycle. The second store stalls because the MSHR is already full by
> that time.
> 
> 
> Diffs
> -----
> 
>   src/mem/packet_queue.cc fbdaa08aaa426b9f4660c366f934ccb670d954ec 
> 
> Diff: http://reviews.gem5.org/r/2784/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Tony Gutierrez
> 
>

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to