Hi Brad (and others), Sorry for my delay on this. Since running into this issue, I've decided that a better solution for the problem I'm experiencing is to bring this other simulator into line with the way Ruby functional accesses are meant to work (i.e. for very infrequent, typically non-cache-resident accesses).
If I run into major issues here, I may reflect back on making some of these changes in Ruby, but for now, I'd like to avoid the complexity involved in making potentially major changes. Thanks for all the input, Joel On Tue, Apr 17, 2012 at 12:28 AM, Beckmann, Brad <[email protected]>wrote: > 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 > -- Joel Hestness PhD Student, Computer Architecture Dept. of Computer Science, University of Wisconsin - Madison 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
