The reason why the requests cannot be processed is not a resource issue. It is usually an address contention issue. When the address contention issue is resolved, a large racey burst of requests is issued at once. That is exactly the type of scenario that finds protocol bugs. The request buffering you are referring to is not in the queued port, rather the buffering occurs in the Sequencer (or other similar objects). The queued port buffering happens on the response path back to the RubyTester. The RubyTester itself can deal with a very large amount of responses at once. The queued port limit is reached simply because a large number of responses come back at once.
Brad -----Original Message----- From: gem5-dev [mailto:[email protected]] On Behalf Of Nilay Vaish Sent: Wednesday, May 13, 2015 9:47 AM To: gem5 Developer List Subject: Re: [gem5-dev] Review Request 2776: ruby: cleaner ruby tester support On Wed, 13 May 2015, Brad Beckmann wrote: > > >> On May 12, 2015, 5:45 a.m., Andreas Hansson wrote: >>> src/mem/packet_queue.cc, line 117 >>> <http://reviews.gem5.org/r/2776/diff/1/?file=45138#file45138line117> >>> >>> I strongly disagree with this change. This buffer should not >>> exist, and even 100 packets is a stretch. Any module hitting this >>> needs to recondiser how it deals with flow control >> >> Brad Beckmann wrote: >> I would agree with you that the buffer should not exist, but removing >> the buffer goes well beyond this patch. The worst part about the buffer is >> the size is not visible to the sender. It is a really bad design, but for >> now we need to get around the immediate problem. Later we can discuss how >> and who will fix this right. >> >> We've discussed the proposal in the past to increase the size, but >> unfortunately we have not came to a resolution. We absolutely need to >> resolve this now. We cannot use the ruby tester with our upcoming GPU model >> without this change. >> >> The important thing to keep in mind is that the RubyTester is designed >> to stress the protocol logic and it creates contention scenarios that would >> not exist in a real system. The RubyTester finds bugs in the matter of >> seconds that may not be encountered in hours of real workload simulation. >> It does this by sending large bursts of racey requests. Bottomline: the >> RubyTester needs this large value. >> >> Andreas Hansson wrote: >> I would argue that if you need flow control, you should not use the >> QueuedPorts, and rather use a "bare-metal" MasterPort, and deal with the >> flow control. There is no point in adding flow control (or buffer >> visibility) to the QueuePort in my opinion. >> >> I'd suggest to switch to a MasterPort either as part of this patch, or a >> patch before it. That way you have no implicit buffer, and no need to create >> kilobytes of invisible buffering in the system. > > The RubyPort and the Ruby Tester predate MasterPorts and QueuedPorts. > Your suggestion goes far beyond this patch. Reimplementing RubyPort's > m5 ports to inherit from a different base port is a very signficant > change with many, many implications beyond the Ruby Tester. That is a > pretty unreasonable request. > > Please keep in mind that I was not the one who decided RubyPort to use > QueuedPorts. That decision was made back in 2012 with patches from > your group 8914:8c3bd7bea667, and 8922:17f037ad8918. > > Brad, I think you are forgetting one thing here. If the packets / memory requests are in a packet queue of the queuedport, then they have not been seen by the ruby memory system. So, if your memory system cannot process requests at the rate at which the tester is issuing them, you are any way not going to see the desired behavior. In which case buffering them in the tester should also be OK. -- 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
