Hi Steve, I did not consider that option, but giving it some more thought it might be possible to have a few different options. We would still have to remove the "is inhibited" check in e.g. the memory and timing ports such that the bus at least gets the opportunity to deal with the requests and responses. The backwards-compatible bus could perform the "is inhibited" check before sending the request out (and thus mimic what is currently done).
I'll give it some more thought and try and implement both options. Andreas -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Steve Reinhardt Sent: 17 June 2012 23:37 To: gem5 Developer List Subject: Re: [gem5-dev] memInhibit and the memory system Hi Andreas, This seems like a reasonable thing to add. However, I'm leery of making such a significant backwards-incompatible change to the existing bus. Is it possible to use this as a test case for implementing multiple protocols, and provide two different bus variants (or a single bus model with an option) such that we provide both behaviors going forward? I realize that's more complicated than having a single model, but in the long run we should have the flexibility to have multiple models anyway, so I'm just thinking this might be a good point to start on that. Steve On Wed, Jun 13, 2012 at 4:33 AM, Andreas Hansson <[email protected]>wrote: > Hi everyone, > > As I understand it, memInhibit is currently used for two purposes: > > > 1) For the caches to communicate whether a line is present in another > cache or not > > 2) To squash the request (and response) destined for a memory > > There are two problems with (2) and I am keen to try and remove this in a > subsequent patch. First, for a bus we would like to model the effects of > speculative fetches, and the implications of snoop latencies compared to > the memory latency. To do so the bus would have to be responsible for the > "aggregation" of the response. Second, for the DRAM modelling, faking the > removal of the inhibited requests changes the behaviour, as the memory is > effectively a state machine (or rather a whole bunch of them). Thus, > squashing the request instead of completing it and later coalescing it in > the bus makes it difficult to investigate the system performance, and > implications of speculative fetches. > > For the aforementioned reasons I would like to keep (1), but try and > remove (2), i.e. remove the check in tport, simple_mem etc, and then add > enough intelligence in the coherent bus to aggregate the response (kill > whichever comes last, snoop response or memory response). > > Any objections, suggestions, ideas? > > Thanks, > > Andreas > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > 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 -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
