Hey guys, I've dug into this some more, and this challenge looks pretty complex. For some detail on what's happening, I'm trying to integrate another simulator in with gem5, and I need to use functional accesses to get data that this other simulator needs in the functional aspects of it's simulation.
As I mentioned previously, when using Ruby, if a cache line happens to be in the busy state on a functional access (e.g. if it is being passed between caches in most protocols), the RubyPort doesn't know how to grab the data on a functional read, or which data to update on a functional write. The current code handles read-write and read-only data in the caches, but doesn't handle this busy state. @Brad, Nilay: I tracked down some conversation you've had about functional access in a previous thread (here: http://www.mail-archive.com/[email protected]/msg12120.html "[gem5-dev] Functional Memory Accesses in Ruby"), in which you articulate the exact problems that I'm dealing with here. Unfortunately, the assumption that Ruby should not handle functional access when a cache line is in an intermediate state has given me some major problems with the integration I'm working on (at least 5 of my 12 preliminary benchmarks). 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? 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? Thanks! Joel -------- 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). On Mon, Mar 19, 2012 at 9:41 AM, Andreas Hansson <[email protected]>wrote: > As we already saw with one of the Ruby regressions, the changes in the > port proxies did expose similar issues already (see changeset > f2ac0bca75df). In short, I am fairly confident that the port proxies are > not the source of the problem. > > I think it boils down to the access permissions in Ruby, but wouldn't know > how/what to change. Nilay? > > Andreas > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Gabe Black > Sent: 19 March 2012 06:42 > To: [email protected] > Subject: Re: [gem5-dev] Debugging New Translating Ports / PortProxy > > Somewhat tangential to the problem you're having, the SE/FS merge and > the change to how ports work were pretty much entirely unrelated, they > just happened to go in around the same time. What you describe sounds > like it could be from the ports change, but, at least from what you've > described, I don't think the SE/FS merge is a factor. > > Gabe > > On 03/18/12 14:54, Nilay Vaish wrote: > > On Fri, 16 Mar 2012, Joel Hestness wrote: > > > >> Hey guys, > >> I just updated my repo to the gem5 head, and I'm trying to merge my old > >> patches. It looks like the TranslatingPort that used to be the O3CPU > >> funcport has changed, and I run into a fatal when trying to run the new > >> code. > >> > >> I'm trying to run simulation with x86 O3CPU, full_system=False (SE > >> mode), > >> and using a Ruby cache hierarchy. With the old code, the O3CPU would > >> simply use the funcport (before the FS/SE merge) to read from the > >> physmem > >> directly (::aside:: this already confuses me, since if the data is > >> modified > >> in a cache, shouldn't that data be read?). With the updated gem5 > >> code, the > >> functional access uses the O3CPU's data port, which is connected to a > >> Ruby > >> sequencer (more as I would expect), which checks to see if the data > >> is in a > >> cache before grabbing the data for the read. > > > > I think the first thing that you need look at is as to why the O3 CPU > > is trying to make functional accesses. I rolled back the repo to look > > if there is any entity by the name funcport, but grep did not provide > > any results. Which code are you referring to? > > > >> > >> The problem that I'm running into is in RubyPort.cc: When the > >> functional > >> read gets to the cache hierarchy, Ruby finds that the > >> AccessPermission on > >> the data it's looking for is in the Busy state (in > >> RubyPort::M5Port::doFunctionalRead(PacketPtr pkt) the num_busy value > >> is 2 > >> since the data is currently in the process of being transferred up the > >> cache hierarchy in a timing request). Because it's in the busy state, > >> doFunctionalRead returns false, which > >> causes RubyPort::M5Port::recvFunctional to fall into the if-statement > >> checking if the access failed (line 445). > >> > >> In this case, couldn't the functional read just grab the data from > >> memory? If so, shouldn't there be better signalling between the > >> doFunctional<type> functions and recvFunctional in RubyPort::M5Port to > >> indicate the access permissions on the data? Suggestions on how this > >> might > >> be fixed? > > > > It is possible that the data in the memory is not up to date, as you > > mentioned before. In fact, busy = 2 means that there are two > > controllers in transient states, so the data might be in the network. > > You might want to look at the access permissions of the transient > > states and decide if it would be safe to read data from one of the > > controllers. If it is, then you can change the access permissions > > accordingly. > > > > -- > > Nilay > > _______________________________________________ > > 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 > -- Joel Hestness PhD Student, Computer Architecture Dept. of Computer Science, University of Texas - Austin http://www.cs.utexas.edu/~hestness _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
