A regression like that would eventually be useful, but right now I would be most appreciative if http://reviews.gem5.org/r/1118/ (and the pile of patches depending on it) was not in the critical path, and it also doesn't change any behaviour with respect to Ruby, it merely adds the snoop/non-snoop separation.
Thanks, Andreas From: Steve Reinhardt [mailto:[email protected]] Sent: 12 April 2012 01:07 To: gem5 Developer List Cc: Nilay Vaish; Andreas Hansson Subject: Re: [gem5-dev] Review Request: MEM: Separate snoops and normal memory requests/responses Is there an SE-mode O3/ruby/x86 regression we can add? On Wed, Apr 11, 2012 at 4:51 PM, Nilay Vaish <[email protected]<mailto:[email protected]>> wrote: > On April 5, 2012, 9:34 a.m., Nilay Vaish wrote: > > src/mem/ruby/system/RubyPort.cc, line 708 > > <http://reviews.gem5.org/r/1118/diff/2/?file=25363#file25363line708> > > > > Andreas, this packet is sent to invalidate loads in the LSQ. This > > packet was earlier handled in the LSQ's recvTiming() function. Since that > > code for snooping is being moved to recvTimingSnoop(), I think this code > > should change as well. > > Andreas Hansson wrote: > It seems this is not used in any regression...so I simply did not catch > it. Fixed now and a new diff to come in a min or two. > > Andreas Hansson wrote: > It would be great if you can give it a bash with your set-up and give it > a "ship it" if things are fine. > > Andreas Hansson wrote: > Hi Nilay, > > Any chance you managed to try this out? > > Nilay Vaish wrote: > Nope. > > Andreas Hansson wrote: > Is there I test I can run that will exercise this piece of code? There is none, I don't think any one uses ruby and o3 cpu currently. I am planning to commit a full system regression test for o3 cpu, ruby and x86 combination. This will have to wait since I am struggling with some error that I see while booting. It seems, I might be speaking too early, that SE/FS merge broke some thing some where. It will take some time (2-3 days) before I can be definitive on this issue. I will run your patch after that. - Nilay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1118/#review2448 ----------------------------------------------------------- On April 10, 2012, 11:25 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1118/ > ----------------------------------------------------------- > > (Updated April 10, 2012, 11:25 a.m.) > > > Review request for Default. > > > Description > ------- > > MEM: Separate snoops and normal memory requests/responses > > This patch introduces port access methods that separates snoop > request/responses from normal memory request/responses. The > differentiation is made for functional, atomic and timing accesses and > builds on the introduction of master and slave ports. > > Before the introduction of this patch, the packets belonging to the > different phases of the protocol (request -> [forwarded snoop request > -> snoop response]* -> response) all use the same port access > functions, even though the snoop packets flow in the opposite > direction to the normal packet. That is, a coherent master sends > normal request and receives responses, but receives snoop requests and > sends snoop responses (vice versa for the slave). These two distinct > phases now use different access functions, as described below. > > Starting with the functional access, a master sends a request to a > slave through sendFunctional, and the request packet is turned into a > response before the call returns. In a system without cache coherence, > this is all that is needed from the functional interface. For the > cache-coherent scenario, a slave also sends snoop requests to coherent > masters through sendFunctionalSnoop, with responses returned within > the same packet pointer. This is currently used by the bus and caches, > and the LSQ of the O3 CPU. The send/recvFunctional and > send/recvFunctionalSnoop are moved from the Port super class to the > appropriate subclass. > > Atomic accesses follow the same flow as functional accesses, with > request being sent from master to slave through sendAtomic. In the > case of cache-coherent ports, a slave can send snoop requests to a > master through sendAtomicSnoop. Just as for the functional access > methods, the atomic send and receive member functions are moved to the > appropriate subclasses. > > The timing access methods are different from the functional and atomic > in that requests and responses are separated in time and > send/recvTiming are used for both directions. Hence, a master uses > sendTiming to send a request to a slave, and a slave uses sendTiming > to send a response back to a master, at a later point in time. Snoop > requests and responses travel in the opposite direction, similar to > what happens in functional and atomic accesses. With the introduction > of this patch, it is possible to determine the direction of packets in > the bus, and no longer necessary to look for both a master and a slave > port with the requested port id. > > In contrast to the normal recvFunctional, recvAtomic and recvTiming > that are pure virtual functions, the recvFunctionalSnoop, > recvAtomicSnoop and recvTimingSnoop have a default implementation that > calls panic. This is to allow non-coherent master and slave ports to > not implement these functions. > > > Diffs > ----- > > src/arch/x86/pagetable_walker.hh 5534a564f6a0 > src/arch/x86/pagetable_walker.cc 5534a564f6a0 > src/cpu/base.hh 5534a564f6a0 > src/cpu/base.cc 5534a564f6a0 > src/cpu/inorder/cpu.hh 5534a564f6a0 > src/cpu/inorder/cpu.cc 5534a564f6a0 > src/cpu/o3/cpu.hh 5534a564f6a0 > src/cpu/o3/cpu.cc 5534a564f6a0 > src/cpu/o3/lsq.hh 5534a564f6a0 > src/cpu/o3/lsq_impl.hh 5534a564f6a0 > src/cpu/simple/atomic.hh 5534a564f6a0 > src/cpu/simple/timing.hh 5534a564f6a0 > src/cpu/simple/timing.cc 5534a564f6a0 > src/cpu/testers/directedtest/RubyDirectedTester.hh 5534a564f6a0 > src/cpu/testers/directedtest/RubyDirectedTester.cc 5534a564f6a0 > src/cpu/testers/memtest/memtest.hh 5534a564f6a0 > src/cpu/testers/memtest/memtest.cc 5534a564f6a0 > src/cpu/testers/networktest/networktest.hh 5534a564f6a0 > src/cpu/testers/networktest/networktest.cc 5534a564f6a0 > src/cpu/testers/rubytest/RubyTester.hh 5534a564f6a0 > src/cpu/testers/rubytest/RubyTester.cc 5534a564f6a0 > src/dev/io_device.hh 5534a564f6a0 > src/dev/io_device.cc 5534a564f6a0 > src/mem/bridge.hh 5534a564f6a0 > src/mem/bridge.cc 5534a564f6a0 > src/mem/bus.hh 5534a564f6a0 > src/mem/bus.cc 5534a564f6a0 > src/mem/cache/base.hh 5534a564f6a0 > src/mem/cache/cache.hh 5534a564f6a0 > src/mem/cache/cache_impl.hh 5534a564f6a0 > src/mem/mport.hh 5534a564f6a0 > src/mem/mport.cc 5534a564f6a0 > src/mem/packet_queue.hh 5534a564f6a0 > src/mem/packet_queue.cc 5534a564f6a0 > src/mem/port.hh 5534a564f6a0 > src/mem/port.cc 5534a564f6a0 > src/mem/ruby/system/RubyPort.hh 5534a564f6a0 > src/mem/ruby/system/RubyPort.cc 5534a564f6a0 > src/sim/system.hh 5534a564f6a0 > > Diff: http://reviews.gem5.org/r/1118/diff/ > > > Testing > ------- > > util/regress all passing (disregarding t1000 and eio) > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected]<mailto:[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
