mem-ruby, stdlib: Far atomics fix (#514)

This PR is fixing https://github.com/gem5/gem5/issues/449 by applying
the following changes

1) Setting up alloc_on_atomic=False in the stdlib
This is directly related to the error message reported by the Issue #449

2) Disabling far atomics in stdlib with policy type = 0
There is an invalid transaction error, likely caused by the fact the
current implementation
is expecting a 2 level cache hierarchy whereas the stdlib example only
allocates one
level of caches (L1). This needs further investigation

3) Explicitly clearing the atomic log
Even by disabling far atomics, the execution of atomicPartial was
populating
the atomic log queue without ever clearing it. This caused the OOM
killer in Linux
to detect the leak and to kill it when the physical resources of the
machine no longer
sufficed. IMHO the atomic log interface should be revamped as atomic
users should
be allocating the atomic log only if explicitly needed

src/mem/ruby/protocol/chi/CHI-cache-actions.sm

@@ -2299,6 +2299,7 @@ action(UpdateDataState_FromADataResp, desc="") {
 
     tbe.oldDataBlk := tbe.dataBlk;
     tbe.dataBlk.atomicPartial(tbe.dataBlk, tbe.atomic_op);
+    tbe.dataBlk.clearAtomicLogEntries();
     tbe.dataDirty := true;
 
     DPRINTF(RubySlicc, "Atomic after %s\n", tbe.dataBlk);
@@ -3424,6 +3425,7 @@ action(Callback_AtomicHit, desc="") {
   DataBlock oldDataBlk;
   oldDataBlk := tbe.dataBlk;
   tbe.dataBlk.atomicPartial(tbe.dataBlk, tbe.atomic_op);
+  tbe.dataBlk.clearAtomicLogEntries();
 
   sequencer.atomicCallback(tbe.addr, oldDataBlk, false);
   DPRINTF(RubySlicc, "Atomic after %s\n", tbe.dataBlk);
@@ -3490,6 +3492,7 @@ action(Callback_Miss, desc="") {
     DataBlock oldDataBlk;
     oldDataBlk := tbe.dataBlk;
     tbe.dataBlk.atomicPartial(tbe.dataBlk, tbe.atomic_op);
+    tbe.dataBlk.clearAtomicLogEntries();
 
     sequencer.atomicCallback(tbe.addr, oldDataBlk, false);
     DPRINTF(RubySlicc, "Atomic after %s\n", tbe.dataBlk);

src/python/gem5/components/cachehierarchies/chi/nodes/abstract_node.py

@@ -85,6 +85,9 @@ class AbstractNode(Cache_Controller):
         # Use 32-byte channels (two flits per message)
         self.data_channel_size = 32
 
+        # Use near atomics (see: https://github.com/gem5/gem5/issues/449)
+        self.policy_type = 0
+
         self.connectQueues(network)
 
     def getBlockSizeBits(self):

src/python/gem5/components/cachehierarchies/chi/nodes/directory.py

@@ -72,6 +72,7 @@ class SimpleDirectory(AbstractNode):
         self.alloc_on_readunique = False
         self.alloc_on_readonce = False
         self.alloc_on_writeback = False
+        self.alloc_on_atomic = False
         self.dealloc_on_unique = False
         self.dealloc_on_shared = False
         self.dealloc_backinv_unique = False

src/python/gem5/components/cachehierarchies/chi/nodes/dma_requestor.py

@@ -56,6 +56,7 @@ class DMARequestor(AbstractNode):
         self.alloc_on_readunique = False
         self.alloc_on_readonce = False
         self.alloc_on_writeback = False
+        self.alloc_on_atomic = False
         self.dealloc_on_unique = False
         self.dealloc_on_shared = False
         self.dealloc_backinv_unique = True

src/python/gem5/components/cachehierarchies/chi/nodes/private_l1_moesi_cache.py

@@ -66,6 +66,7 @@ class PrivateL1MOESICache(AbstractNode):
         self.alloc_on_readunique = True
         self.alloc_on_readonce = True
         self.alloc_on_writeback = False  # Should never happen in an L1
+        self.alloc_on_atomic = False
         self.dealloc_on_unique = False
         self.dealloc_on_shared = False
         self.dealloc_backinv_unique = True