Tony, I noticed the same thing as well and as you mentioned the perf penalty could be really high. http://www.mail-archive.com/gem5-users@gem5.org/msg05894.html I don't know what the reason could be, but I was able to fix this. If I remember right, to prevent squashing, you need to mark those loads with a flag or something and try to add them to instruction queue again.
Thanks, Amin On Thu, Sep 26, 2013 at 6:21 PM, Tony Nowatzki <t...@cs.wisc.edu> wrote: > Hi All, > > Apologies in advance if this is a silly question, or a repeat. > > I recently noticed that the OoO core squashes itself and all younger > instructions when a load is issued to the memory system, but the cache is > blocked (say the MSHRs are full, or there are no targets left). Contrarily, > when a write is issued to the memory system, the store will simply retry > until the cache can handle the request. > > There is potentially some performance penalty in squashing these loads, > and a large energy penalty as well (can be up to 2x for the core in some > contrived cases, according to mcpat). Given that these squashes can occur > frequently in memory-bound programs, is there a reason this was chosen as > the implementation? Is there a reason why loads can't be stalled and > retried on a cache block? > > Thanks! > Tony > ______________________________**_________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/**mailman/listinfo/gem5-users<http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users> >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
