> On July 4, 2012, 4:27 p.m., Steve Reinhardt wrote: > > Ship It! > > Steve Reinhardt wrote: > Actually I'm now having second thoughts about this. The bottom line is > that people really need to carefully specify bus bandwidths for a realistic > system, and no one default is going to be realistic in all situations. I > agree that the current value is unrealistically high (not sure how we ended > up with that), but I'm concerned that cutting it 8X to a mere 8 GBps is going > to introduce a significant bottleneck on multicore systems, to the point > where existing users will get quite surprised when things change dramatically > on them. > > One solution would be to get rid of the default width altogether (and > maybe the default clock too) to force everyone to think about what they're > doing. If we couple that with making sure that reasonable widths & > frequencies are specified in the config files, then it won't break any of our > existing configs or tests. You could even leave the width at 64 in the > regression configs and avoid any impact there (though as you point out, you > have to rerun regressions anyway so that's not a huge practical savings).
I agree that it will change things quite dramatically, but on the other hand, the values that come out will be far more realistic with the 64-bit compared to the 512-bit bus width. Ultimately, if there is a bottleneck, then even the existing users should see it, right? I can send out a mail on the dev and user list highlighting the change to avoid (or at least lessen) surprises. I think the 64-bit is a good option for a default, as it actually is the most common case in actual implementations (as far as I can tell at least). Even though removing the default might force users to think, the same could then be said for a lot of parameters in the system. In conclusion, I'd vote for keeping the default, and changing it to 64 bits (8 bytes), and broadcast the change on the lists. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1267/#review3029 ----------------------------------------------------------- On June 11, 2012, 7:46 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1267/ > ----------------------------------------------------------- > > (Updated June 11, 2012, 7:46 a.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9075:04e848b767d7 > --------------------------- > Bus: Make the default bus width 8 bytes instead of 64 > > This patch changes the default bus width to a more sensible 8 bytes > (64 bits), which is in line with most on-chip buses. Although there > are cases where a wider or narrower bus is useful, the 8 bytes is a > good compromise to serve as the default. > > This patch changes essentially all statistics, and will be bundled > with the outstanding changes to the bus. > > > Diffs > ----- > > src/mem/Bus.py 35ac3a6f8ee0 > > Diff: http://reviews.gem5.org/r/1267/diff/ > > > Testing > ------- > > util/regress all running and producing the right output (disregarding t1000 > and eio) but with essentially all timing tests exhibiting stat differences > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
