Hi Paul, I assume you're talking about the 'wbMax' variable? I don't recall it specifically myself, but after looking at the code a bit, the best I can come up with is that there's assumed to be a finite number of buffers somewhere that hold results from the function units before they write back to the reg file. Realistically, to me, it seems like those buffers would be distributed among the function units anyway, not a global resource, so having a global limit doesn't make a lot of sense. Does anyone else out there agree or disagree?
It doesn't seem to relate to any structure that's directly modeled in the code, i.e., I think you could rip the whole thing out (incrWb(), decrWb(), wbOustanding, wbMax) without breaking anything in the model... which would be a good thing if in fact everyone else is either suffering unaware or just working around it by setting a large value for wbDepth. That said, we've done some internal performance correlation work, and I don't recall this being an issue, for whatever that's worth. I know ARM has done some correlation work too; have you run into this? Steve On Fri, May 9, 2014 at 7:45 AM, Paul V. Gratz via gem5-users < gem5-users@gem5.org> wrote: > Hi All, > Doing some digging on performance issues in the O3 model we and others > have run into allocation of the writeback buffer having a big performance > impact. Basically, the a writeback buffer is grabbed at issue time and > held through till completion. With default assumptions about the number of > available writeback buffers, (x*issue width, where x is 1 by default), the > buffers often end up bottlenecking the effective issue width (particularly > in the face of long latency loads grabbing up all the WB buffers). What > are these structures trying to model? I can see limiting the number of > instructions allowed to complete and writeback/bypass in a cycle but this > ends up being much more conservative than that if it is the intent. If not > why does it do this? We can easily make number of WB bufs high but want to > understand what is going on here first... > Thanks! > Paul > > -- > ----------------------------------------- > Paul V. Gratz > Assistant Professor > ECE Dept, Texas A&M University > Office: 333M WERC > Phone: 979-488-4551 > http://cesg.tamu.edu/faculty/paul-gratz/ > > _______________________________________________ > 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
