Hi guys, I am very much inclined to support Brad's approach, which doesn't care about the "physical" topology of the interconnect.
Also, I don't want to de-rail the discussion, but an idea that I came to think of based on all my previous NoC work, do you really need to enquire the router network at all? Isn't the state always determined what the controllers and end-points see? What happens if the network only sees "packets" and has no clue about the actual higher-level messages (which is the case in plenty real NoC implementations)? Andreas On 06/10/2012 13:36, "Nilay Vaish" <[email protected]> wrote: >On Fri, 5 Oct 2012, Beckmann, Brad wrote: > >> Hi Nilay, >> >> To solve the first problem, can you use the Maybe_Stale >>AccessPermission >> identify the last possible valid copy of the data block? It seems like >> if a functional read can't find valid data anywhere else, then you are >> guaranteed that the Maybe_Stale block at the directory is valid. > >I think this solution will not work. It is possible that two controllers >at two different levels have a block with access permission Maybe_Stale. >In that case, unless we have the hierarchical information, we would not >be >able to figure out which block to read. It seems it would not hard to add >this hierarchy information to the existing protocols, and then we can add >a hierarchical list of controllers to the ruby system. > >> >> With this change, we should be able to get rid of the physmem backing >> store in Ruby, correct? Have you tried that sort of test with this >> patch? Especially an application under SE mode that uses a lot of >> system calls? > >I never thought about removing the backing physical memory. But now that >you mention it, if the cache and directory controllers are the only ones >who should be writing to the memory (which I think is true in the SE >mode), then it should be possible to remove the backing physical memory. >This might lead to bugs being uncovered in the coherence protocols. > >> >> 45 files modified...have I told you how much I dislike this patch. :) > >I agree that a lot of files are being changed. With a high probability, >anyone who has modified Ruby would need to redo his/her patches. But then >I don't see if any changes can be elided. Even if I were to go with your >suggestion of building a flat list of buffers, most of the changes would >still remain as is. > >> >> Brad >> >> >>> -----Original Message----- >>> From: Nilay Vaish [mailto:[email protected]] >>> Sent: Wednesday, October 03, 2012 10:02 PM >>> To: Andreas Hansson; Default; Beckmann, Brad >>> Subject: Re: Review Request: ruby: augment network to support >>>functional >>> accesses >>> >>> Some comments on the patch -- >>> >>> * The way the code has been written, functional writes will always >>>succeed, >>> but functional reads can still fail. This can be illustrated with an >>>example. >>> Consider the situation when the directory has the actual data, but it >>>believes >>> that the ownership of the data is with some other controller. This >>>other >>> controller has relinquished the ownership with out modifying the data. >>>The >>> info about relinquishment is in the network currently. The read would >>>fail >>> since we need to know both pieces of info to figure out that the >>>directory >>> has the data. We would need greater cooperation from protocols for >>>reads >>> to succeed all the time. >>> >>> * I have done some testing with the memtest (1 to 8 cores, 160000 >>>loads). >>> But no testing has been done when dma requests/replies are part of the >>> system. >>> >>> * No support for garnet as of now. >>> >>> * Coherence protocols MI, MOESI CMP token have been changed slightly. >>> These changes have been vetted only with the memtest. >>> >>> -- >>> Nilay >> > >-- >Nilay >_______________________________________________ >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
