Hi, Jason, Can you explain how to annotate the cache coherence protocols to enable bank contention modeling for Ruby?
Thanks, Yuan Jason Power <power.jg@...> writes: > > Hi all, > > On the Ruby side I implemented a similar feature in the caches instead of > in the core model. See src/mem/ruby/system/BankedArray > > This implementation uses annotations to the state transitions within the > cache coherence protocol to model bank and port conflicts and bandwidth > to/from the caches. It is a quite simplistic implementation, and > unfortunately it only applies to Ruby and not the classic caches. > > Just thought I'd point this out so we can try to minimize duplicate work if > possible :). > > Thanks, > > Jason > > On Tue, Jan 8, 2013 at 9:20 AM, Andreas Hansson <andreas.hansson@...>wrote: > > > > > > > > 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 > > gem5-dev@... > > http://m5sim.org/mailman/listinfo/gem5-dev > > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
