On Wed, 16 Feb 2011, Beckmann, Brad wrote:
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
I implemented it, for MOESI CMP directory protocol, I see about a 1%
improvement in performance (when ruby random tester is profiled).
I think there is more room for improvement, especially since lot of the
code is repeated again and again. I need to look more closely at code
generation for trigger().
--
Nilay
-----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
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
