----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1422/#review3788 -----------------------------------------------------------
at first glance this seems like a pretty useful fix. Thanks Amin! Anyone else have thoughts? Andreas, how does this interact with your changes? - Ali Saidi On Sept. 16, 2012, 5:06 p.m., Amin Farmahini wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1422/ > ----------------------------------------------------------- > > (Updated Sept. 16, 2012, 5:06 p.m.) > > > Review request for Default. > > > Description > ------- > > I made some changes to O3 to model the bandwidth between O3 and L1. By > bandwidth I mean the number of requests and responses sent or received each > cycle (not the amount of data transferred). Before putting a patch online, I > would like to get your feedback on it. > Here is what I did to model cache ports for O3. I limit both the number of > requests sent by O3 and the number of responses received by O3. > > For REQUESTS: > I have a separate read requests (loads) counter and a separate write requests > (stores) counter. > LOADS: O3 limits the number of read requests sent each cycle to the number of > defined cache read ports. > STORES: Similarly, O3 limits the number of write requests sent each cycle to > the number of defined cache write ports. > Note that no matter how many ports are defined, we have only a single actual > cache port used for all read and write requests. So just like the current > gem5 code, only one dcachePort is defined in the code. However, I limit the > number of requests to the number of cache ports defined in parameters. > > For RESPONSES: > LOADS: I limit the number of load responses received each cycle to the number > of cache read ports. Once O3 reaches its load response limit, the next load > response in this cycle is rejected and the cache port is blocked until next > cycle. Note that blocking the cache port also inhibits the O3 from receiving > write responses which is not a correct thing, but I don't have any control on > blocking read and write responses separately. > STORES: same as above > > I tried to avoid details such as split packets, pending packets, etc, to give > a brief overview. I don't believe what I implemented is the best way to model > cache ports here, so your feedback would be appreciated. What Steve mentioned > seems a more concrete way to implement it, but lack of my knowledge about bus > code in gem5 pushed me toward modifying the O3 code. > > > Diffs > ----- > > src/cpu/o3/lsq_unit_impl.hh UNKNOWN > src/cpu/o3/lsq_impl.hh UNKNOWN > src/cpu/o3/lsq_unit.hh UNKNOWN > src/cpu/base_dyn_inst.hh UNKNOWN > src/cpu/o3/O3CPU.py UNKNOWN > src/cpu/o3/iew_impl.hh UNKNOWN > src/cpu/o3/inst_queue.hh UNKNOWN > src/cpu/o3/inst_queue_impl.hh UNKNOWN > src/cpu/o3/lsq.hh UNKNOWN > > Diff: http://reviews.gem5.org/r/1422/diff/ > > > Testing > ------- > > a few small benches done only in SE and classic > > > Thanks, > > Amin Farmahini > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
