Hi Andreas, I know it has been several months since this topic was brought up, but I think it is worth trying to come up with a solution here. I also believe this relates to the gem5-users thread "PacketQueue sanity check on its invisible buffer size" started by Lichen Yu back in May.
Can you clarify why you are pushing back on making this size configurable? The size 100 seems pretty arbitrary and is far too small if you consider massively threaded requestors, such as GPUs. Also it doesn't make sense to make these queued ports both finite in size, yet their size is invisible to the requestors. Ideally from the Ruby perspective, I would prefer us to simply remove the panic message from packet_queue.cc. There are other mechanisms in place to model finite buffering and the PacketQueue does not represent the type of hardware buffering we are envisioning. Does that work for you? Brad -----Original Message----- From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson Sent: Monday, March 18, 2013 12:32 AM To: Jason Power; Andreas Hansson; Default; Joel Hestness Subject: Re: [gem5-dev] Review Request: PacketQueue: Add maxQueueDepth parameter and setter > On March 17, 2013, 7:43 p.m., Jason Power wrote: > > Ship It! Sorry to cause problems here guys, but I think we need to fix this another way. The queued port is not supposed to be a "free" storage resource. If it runs out, we should rather block the cache. Overall, I have been thinking about how we can turn the queued port into something that can signal back that it is blocking. It gets a bit tricky as you soon end up removing all the functionality of the queued port and end up with the send/retry style interface. In short: I don't think we should ship this, and I'm keen to hear what people think is a reasonable way to make the queued port "block" it's MemObject (and start it again without polling). - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1777/#review4135 ----------------------------------------------------------- On March 17, 2013, 6:05 p.m., Joel Hestness wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1777/ > ----------------------------------------------------------- > > (Updated March 17, 2013, 6:05 p.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9587:b989f6228833 > --------------------------- > PacketQueue: Add maxQueueDepth parameter and setter > > The default maximum PacketQueue depth of 100 can cause assertion failures when > using the PacketQueue in a setting when the maximum queue depth may be known > to > be greater than 100 (e.g. modeling queuing of outstanding requests to the > cache > from aggressive GPU core implementations). Parameterize this max depth and add > a method to set the max depth. > > > Diffs > ----- > > src/mem/packet_queue.hh 3c62e3b7f658 > src/mem/packet_queue.cc 3c62e3b7f658 > > Diff: http://reviews.gem5.org/r/1777/diff/ > > > Testing > ------- > > > Thanks, > > Joel Hestness > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
