Hello, Generally, it's difficult to queue up writeback requests at the cache controller and maintain coherence. The different cache models in gem5 implement this in different ways.
In the classic caches, the MSHR queues handle the queuing for writebacks. When a line is evicted a writeback request is added the the MSHR queue and it is scheduled for when the port is free. In Ruby, assuming the other required resources are available, the writeback happens immediately. Or the writeback request is pushed into the network immediately. Once in the on-chip network, it is queued by the routers and the buffers in the networks. The exact mechanism depends on how the network is configured (e.g., simple vs garnet model). Finally, there's no reason you can't send more than one packet across a gem5 port in a cycle. It's up to you as the modeler to decide if and how to model contention for your hardware devices. Cheers, Jason On Wed, Sep 9, 2020 at 8:31 AM gokulan97--- via gem5-users < [email protected]> wrote: > I am starting to learn gem5 using the Learning Gem5 book, and encountered > this issue while implementing a non-blocking cache. > > Logic at the cache in case of a miss is to send the demand request for the > miss, and conditionally evict a block back to memory (writeback request). > Now, these two requests cannot be sent in the same cycle since only a > single packet can be sent in a single port in any cycle. Scheduling the > eviction request to a later cycle might contend for the port with demand > requests in the future, so that solution might not work as well. Queueing > up eviction requests and writing them back as and when the port is free is > IMO the best solution, implemented in modern processors as well. While this > might very much be already present in gem5, I'm really missing out on where > I could find it. > > It will be helpful if any leads to how contention of resources is handled > in gem5, in general, can be provided. > _______________________________________________ > gem5-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >
_______________________________________________ gem5-users mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
