Hi Aritra, See answers inline below.
Cheers, Jason On Tue, Sep 15, 2020 at 3:12 AM Aritra Bagchi via gem5-users < gem5-users@gem5.org> wrote: > Hi all, > > I have two questions regarding the classic cache of gem5. They are as > follows: > > 1. Last-level caches in real hardware are usually not monolithic but are > multi-banked. It seems multiple banking can be efficient only if the memory > accesses are spread uniformly across all banks. Can such banking be > implemented in gem5 classic cache? Could someone provide any hint on how to > do that? > Yes and no. You can, in theory, have different Cache objects respond to different address ranges (e.g., an interleaved range) to emulate a banked cache. However, IIRC, the caches currently don't take their interleaved address ranges in to account when calculating index/tag bits. This would need to be fixed to get a multi-banked cache. Banking is implemented in Ruby if you enable the resource constraints and make sure that your protocol correctly marks the tag and data reads and writes. > > 2. I have experimented with gem5 caches and found that a memory request > which is a miss at the last-level cache (L3) has to traverse the entire > memory hierarchy: L1-D (miss) > L2 (miss) > L3 (miss) > main memory (fetch > data) > L3 (miss-fill/write) > L2 (miss-fill/write) > L1-D > (miss-fill/write) . When the response comes from the main memory, I want to > bypass it to the L2 cache and let the miss-fill happen independently at L3 > taking whatever latency it should take for an L3 write operation. I wanted > to make sure that the requesting core does not have to stall (wait) for the > miss-fill to finish, and can get the data as soon as it becomes available > from the main memory. Could someone put some light on how can this be > implemented in gem5? > I think you'd have to modify the cache implementation. That said, it may not be realistic to have a bypass bus (and extra set of wires routing around the L3 cache) in real systems. Generally, if you care about modeling the cache protocol or the on chip network in detail, Ruby is the better model. > > Any comment/suggestion/clarification will be highly appreciated. > > Thanks and regards, > Aritra > _______________________________________________ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
