Hi all, Since then I have made a lot of changes to this patch. For responses, I have added that feature in the caches instead of in the core model (only to classic mode). Basically, I got rid of retry packets and queued packets in the cache if the port is not free this cycle. Next week, I can submit my new patch that includes those changes. I have a deadline this week, but I can get back to you next week.
Thanks for looking at this patch. Amin On Tue, Jan 8, 2013 at 9:38 AM, Jason Power <[email protected]> wrote: > 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 > <[email protected]>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 >> [email protected] >> http://m5sim.org/mailman/listinfo/gem5-dev >> > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
