Hello list members,
I'm running PARSEC benchmarks on a system with 4 timing CPUs in a 2-cluster
formation with an L2 per cluster, and private I&D L1 caches per CPU.
Some of my simulations break because of the following assertion:
lru.cc:
void LRU::invalidateBlk(BlkType *blk)
{
...
assert(blk->srcMasterId < cache->system->maxMasters());
One of the CPUs issues a write to its dcache, causing a miss, resulting in
a read-exclusive request.
While handling the response, the L2 cache's handleResponse calls
handleFill, which calls allocateBlock (hence a replacement is needed), yet
allocation fails, causing the cache to use tempBlock to complete the
current request.
handleResponse eventually calls satisfyCpuSideRequest with the tempBlock.
since this is a 2-level cache hierarchy, invalidateBlk is called.
And here is the problem:
The block used is the tempBlock, which was assigned with a default-value
srcMasterId, causing the assertion to fail.
>From a hesitant guess, I think LRU::invalidateBlk isn't intended to be
called with tempBlock.
Even if the tempBlock would have a valid srcMasterId, moveToTail() would
fail as tempBlock isn't a block from any set, and the following assertion
would fail:
cacheset.cc:
void CacheSet::moveToTail(CacheBlk *blk)
{
...
assert(i >= 0);
The general scenarios I'm trying includes slowing down snoop responses.
This might cause the L2 to fill its mshr, starting this whole mess.
Does this seem like a plausible scenario?
Thanks,
Uri
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
