I just posted the patch for review; see http://reviews.gem5.org/r/2277. It may depend on some of the other patches I posted immediately prior to it, particularly 2276.
Steve On Mon, May 5, 2014 at 9:32 AM, Adrián Colaso Diego via gem5-users < gem5-users@gem5.org> wrote: > It sounds good, i will wait for that patch. > > Thank you. > Adrian > > El lun, 05-05-2014 a las 09:22 -0700, Steve Reinhardt via gem5-users > escribió: > > We have an internal patch that generates an exclusive prefetch when a > > store is issued, which greatly relieves the store bottleneck. We were > > in the process of getting it cleaned up to post but things got bogged > > down somewhere. I'm going to go see what happened to it and if we can > > revive it. > > > > > > Steve > > > > > > On Mon, May 5, 2014 at 9:05 AM, Mitch Hayenga via gem5-users > > <gem5-users@gem5.org> wrote: > > Yep, the single-store in flight is a significant limitation of > > TSO. There are things you can do to alleviate it (which gem5 > > doesn't do). > > > > > > A cpu could speculatively try to obtain ownership for a > > cacheline before a store were fully committed. Thus the store > > could be retired much more quickly to the L1 cache once it was > > committed. This is because the L1 would likely retain > > ownership. > > > > > > > > Additionally, real CPUs split stores in to "store address" and > > "store data" micro-ops. A real CPU could speculatively try to > > obtain cache line ownership as soon as the store address were > > known (before the data). I don't know about the x86 > > implementation in gem5, but I'd guess it doesn't do this > > decomposition of stores. > > > > > > I'm sure if anyone tried to hack this "speculative ownership" > > into gem5, many would be appreciative. > > > > > > > > > > On Mon, May 5, 2014 at 10:47 AM, Srinivasan Narayanamoorthy > > via gem5-users <gem5-users@gem5.org> wrote: > > Hi, > > > > That can happen.. But why is the behavior you describe > > not acceptable? if another structure is added, then > > incoming snoops have to CAM into that structure too > > and hardware implementation wise, may be not > > efficient. > > > > > > Thanks > > Srini > > > > On 05/05/14, Adrián Colaso Diego via gem5-users > > wrote: > > > Hi, > > > > > > I've noticed than when you run gem5 using X86 iSA > > there is a huge > > > bottleneck in SQ due to TSO implementation as only > > one store is allowed > > > to be in flight. As a consequence old stores that > > are waiting to access > > > memory and that aren't present in ROB saturate SQ > > structure. > > > > > > I think that these old stores should be inserted in > > another structure > > > not to saturate SQ as what i see in results files is > > that cpu is stalled > > > half of simulation cause SQ is full. > > > > > > Has anybody experimented what i describe? > > > > > > Thanks, > > > Adrian. > > > > > > > > > _______________________________________________ > > > gem5-users mailing list > > > gem5-users@gem5.org > > > 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 > > > > > > > > > > _______________________________________________ > > gem5-users mailing list > > gem5-users@gem5.org > > 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 > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > 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
