Hi Licheng,
Ultimately I would suggest we move away from using queued ports in the cache.
As you say, it should be blocking, and rather than re-inventing flow control on
the input of the queue, I would think the easiest is to use "raw" ports
altogether.
If someone has time to mock up a patch doing the above that would be great.
Andreas
From: YuLicheng <[email protected]<mailto:[email protected]>>
Reply-To: gem5 users mailing list
<[email protected]<mailto:[email protected]>>
Date: Friday, 17 May 2013 14:31
To: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: [gem5-users] PacketQueue sanity check on its invisible buffer size
Hi,
The PacketQueue has following code in PacketQueue::schedSendTiming:
// add a very basic sanity check on the port to ensure the
// invisible buffer is not growing beyond reasonable limits
if (transmitList.size() > 100) {
panic("Packet queue %s has grown beyond 100 packets\n",
name());
}
Since the buffer is invisible to it’s master, what if the master is to much
faster than the slave?
Suppose a fast processor accesses cache in a very short interval, and the
cache then pushes all it’s
memory requests to the memory side PacketQueue without knowing the queue is
growing.
And finally: panic: Packet queue system.cache.mem_side-MemSidePort has grown
beyond 100 packets.
So what is the correct manner to deal with this. Understanding that the
PacketQueue is used for
flow control, shoud the cache be blocked when it is runing too fast that its
outcoming queue is full?
Thanks.
Yours, Licheng.
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you._______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
