On Fri, Apr 13, 2012 at 10:15 AM, Nilay Vaish <[email protected]> wrote:
> On Mon, 9 Apr 2012, Joel Hestness wrote: > > I'm hoping you guys could clarify a couple things for me: >> 1) It's not clear to me whether the messages passed between cache >> controllers contain copies of the data being transferred, or if they just >> contain pointers to locations which contain the data to be transferred. >> This is important if, during a functional write in an intermediate state, >> there is a copy of the data that is not pointed to by the caches that are >> being updated. Can you clarify this? >> > > Messages do contain data, and it is conceivable that during some > particular transcation, the data would be in the interconnection network > for some time. Hence, it is not possible at all times to honour a function > read/write request. The way the classic memory system works is that interconnect components that buffer state have to implement functional access methods that check whether data in a buffered packet should be read or written (see for example http://repo.gem5.org/gem5/file/5de232ed3a28/src/mem/bridge.cc#l440). Brad and I have discussed this, and my impression is that this is also feasible for Ruby, though Brad thinks it would be a headache to graft it on to all the existing network models (paraphrasing his opinion from my faulty memory). Nevertheless I think it should be done eventually. Brad tends to push back, probably because he rightly fears that he would be the one to end up doing it ;-). The key point is that "not possible" is an overstatement. > 2) Can you also clarify what the RubyPort::M5Port variable >> access_phys_mem is supposed to indicate? If set, does this mean that the >> physical memory actually contains the most up-to-date (possibly even dirty >> cache line) data? >> >> > The access_phys_mem denotes whether or not a copy of the entire memory is > being maintained. You might know that as of now, programmed IO accesses do > not flow through ruby. So it is not possible to maintain a correct copy of > all the data. Hence, is separate copy of the memory is maintained, which > gets to see all the read/write operations. Do we only turn on access_phys_mem for full-system simulations then? > >> -------- Other scribblings for the record -------- >> Making this more complex is that in order for this functional access code >> to work with other Ruby protocols, this solution will have to be generic >> to >> handle different types of intermediate states. I think the correct way >> for >> this to work is the following: >> - On functional reads, find the cache(s) that contains the most recent >> data (e.g. modified, exclusive or shared), and read the portion of the >> line >> that the functional access needs. If the line does not exist in caches, >> just read from memory. >> - On functional writes, find the cache(s) that contains the most recent >> data (e.g. modified, exclusive or shared), and write the portion of the >> line that the functional access needs. If the write switches the cache >> line's state (e.g. exclusive to modified), update the appropriate state. >> If the line does not exist in caches, simply forward the request on to >> memory (this includes if we update lines in the shared state that aren't >> dirty). >> >> > This is exactly what is being done. The problem is that at times none of > caches / memory controller may have the data. My understanding is that, in addition to cases where the only valid data is in the network (discussed above), there may also be cases where the data is in the caches or memory but in some intermediate protocol state such that it's not clear if it's the latest version, and it would require manual effort to identify all the possible protocol states and whether they should be considered valid for the purposes of responding to a functional request. Again, this is a potentially faulty recollection based on prior conversations with Brad. Overall I would love to see full support for functional accesses in Ruby, and we may reach a point where we really need to figure out how to make it happen (maybe we are reaching it now). It's not a simple task, but maybe we should brainstorm on how to simplify it, or decide that we can't do it all at once but can have a plan to get there incrementally. Brad really needs to be part of that discussion though, and he's off at the baseball game today... Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
