> On Jan. 8, 2013, 6:22 a.m., Ali Saidi wrote: > > at first glance this seems like a pretty useful fix. Thanks Amin! Anyone > > else have thoughts? Andreas, how does this interact with your changes?
I have some reservations. I agree that it is a very useful addition, I am just not thrilled with the way it is done. If we really want to separate reads and writes, then we should check them separately in recvResponse and deal with them independently (do we really want to separate them?). Moreover, we should not send a retry the next cycle, but rather when a response comes back and frees up a "port". - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1422/#review3788 ----------------------------------------------------------- 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 [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
