Hi Nilay, I'm not quite sure what you mean by "appended to while you drain", but I think you are asking whether the input ports will receive messages that are scheduled for the same cycle as the current cycle. Is that right? If so, then you are correct, that should not happen.
As long as the input ports are evaluated in the current order of priority, you're change looks good to me. In the past, one could limit the loop iterations per cycle to approximate cache port contention. Therefore the higher priority ports must be listed first to avoid mandatory requests starving external responses. Brad > -----Original Message----- > From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On > Behalf Of Nilay Vaish > Sent: Tuesday, February 15, 2011 9:09 AM > To: M5 Developer List > Subject: Re: [m5-dev] CacheController's wakeup function > > On Tue, 15 Feb 2011, nathan binkert wrote: > > > While I don't know anything about this code it looks a little suspect > > to me. Is there really a while (true) or is there some sort of while > > (!empty)? Can the queues be appended to while you drain? If these > > are both true, then you'll lose some of your enqueued messages. > > > > Sorry if I'm uninformed. > > > > It is a while(true), and there is break statement which is executed in > case none of the queues have any messages. I am almost certain that the > incoming queues do not get appended to while they are being drained, I > would like Brad to confirm this. > > -- > Nilay > > >> I thought of this a moment ago, so I have not confirmed this > empirically. > >> The CacheController's wakeup function includes a while loop, in > which all > >> the queues are checked. Consider the Hammer protocol's L1 Cache > Controller. > >> It has four incoming queues - trigger, response, forward, mandatory. > The > >> wakeup function looks like this -- > >> > >> while(true) > >> { > >> process trigger queue; > >> process response queue; > >> process forward queue; > >> process mandatory queue; > >> } > >> > >> where process means processing a single message from the queue. > >> I expect most of the messages to be present in the mandatory queue > which > >> processes the actually loads and stores issued by the associated > processor. > >> Would the following be better -- > >> > >> while(true) process trigger queue; > >> while(true) process response queue; > >> while(true) process forward queue; > >> while(true) process mandatory queue; > >> > >> I do not expect any improvement in case of FS profiling as most of > the > >> times, the mandatory queue has only one single message. But for > testing > >> protocols using ruby random tester, I do expect some improvement. In > FS > >> profile, after the histogram function (which takes about 8% time), > the > >> wakeup function's execution time is the highest (about 5%). For ruby > random > >> tester profile, the wakeup function takes about 11% of the time. > >> > >> -- > >> Nilay > >> _______________________________________________ > >> m5-dev mailing list > >> m5-dev@m5sim.org > >> http://m5sim.org/mailman/listinfo/m5-dev > >> > >> > > _______________________________________________ > > m5-dev mailing list > > m5-dev@m5sim.org > > http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
