On Sunday 07 March 2010 01:32:09 am Ali wrote:
> Hi Stijn,
>
> They are just snoop requests from the access filtering through the
> system. You might be able to stop them by having the CPU return
> snoop=false to getDeviceAddressRanges(), but I'm not sure that the
> caches have code to do that implemented (Steve?). In any case, it's
> certainly OK to ignore them in the atomic simple cpu since it doesn't
> have any sort of buffering for the requests. The other CPU models
> ignore them as well, although it's possible that the snoop order could
> be used to enforce a stronger ordering in the system (although no one
> has ever tried this).
>
> Hope this helps,
> Ali
Hi again,
Good news this time. I managed to get it working, or at least, it seems to
work fine functionally for some non-trivial benchmarks, though I need to do
some more tests. As suggested I simply abort Cache<TagStore>::atomicAccess in
case of a miss at the time of calling memSidePort->sendAtomic but in the case
of a writeback I can't abort Cache<TagStore>::atomicAccess completely but
catch deadlocks in the while loop and repeat as following:
while (!writebacks.empty()) {
PacketPtr wbPkt = writebacks.front();
try {
this->enableRollBack();
memSidePort->sendAtomic(wbPkt);
writebacks.pop_front();
delete wbPkt;
} catch (ExclusiveResource::DeadLockException ex) {
this->unlockOnce(); // other thread gets priority
this->lockOnce();
//throw ex;
}
}
Aborting atomicAccess completely when a writeback deadlocks results in
functional errors in the program so I have to do it like this, which is more
efficient anyway. Can anyone foresee any simulation errors resulting from
interrupting writebacks as such that could lead to inconsistencies?
The deadlock frequency seems to be acceptable, a couple of times a second
(will measure more accurately later). However as I expected, there seems to be
a lot of contention as the number of cores increases so I'll probably have to
manage thread priority a bit better for higher amounts of cores.
Thanks for the help,
Stijn
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
