Hi Joel, Sorry for the slow reply...is this still an issue? Since you and Nilay are now working on the same floor, did you resolve this locally instead of via email?
Brad > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Joel Hestness > Sent: Monday, April 09, 2012 3:56 PM > To: gem5 Developer List > Subject: Re: [gem5-dev] Debugging New Translating Ports / PortProxy > > 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 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
