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]> 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] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
