Using recycle in the L2 controllers to put messages back into the buffer
may lead to starvation when there are many L1 requests for the same line.
This can easily trigger the deadlock detection mechanism in configurations
with many cores (16+). Replacing recycle by stall_and_wait for L1
requests avoids this issue. wakeUpBuffers calls were added to all
transitions from transient to stable states.
Change-Id: I28b8aeacc48919ccf38e69653cd9205a4153514b
Signed-off-by: Tiago Muck <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/17568
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously all atomic writebacks concerned a single block,
therefore, when a block was evicted, no other block would be
pending eviction. With sector tags (and compression),
however, a single replacement can generate many evictions.
This can cause problems, since a writeback that evicts a block
may evict blocks in the lower cache. If one of these conflict
with one of the blocks pending eviction in the higher level, the
snoop must inform it to the lower level. Since atomic mode does
not have a writebuffer, this kind of conflict wouldn't be noticed.
Therefore, instead of evicting multiple blocks at once, we
do it one by one.
Change-Id: I2fc2f9eb0f26248ddf91adbe987d158f5a2e592b
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18209
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
When a block in compressed form is overwriten, it may change
its size. If the new compressed size is bigger, and the total
size becomes bigger than the block size, one or more blocks
will have to be evicted. This is called data expansion, or
fat writes.
This change assumes that a first level cache cannot have a
compressor, since otherwise data expansion should have been
handled for atomic operations and writes. As such, data
expansions should only be seen on writebacks. As writebacks
are forwarded to the next level when failed, there should
be no data expansions when servicing misses either.
This patch adds the functionality to handle data expansions
by evicting the co-allocated blocks to make room for an
expanded block.
Change-Id: I0bd77bf6446bfae336889940b2f75d6f0c87e533
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/12087
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Implement a co-allocation function in compressed tags, so
that compressed blocks can be co-allocated in a superblock.
Co-allocation is possible when compression ratio (CR) blocks
that share a superblock tag can be compressed to up to (100/CR)%
of their size.
Change-Id: I937cc1fcbb488e70309cb5478c12db65f1b4b23f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/11411
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Add compression statistics to the compressors. It tracks
the number of blocks that can fit into a certain power
of two size, and the number of decompressions.
For example, if a block is compressed to 100 bits, it will
belong to the 128-bits compression size. Although it could
also fit bigger sizes, they are not taken into account for
the stats (i.e., the 100-bit compression will fit only the
128-bits size, not 256 or higher).
We save stats for compressions that fail (i.e., compressed
size is bigger than original cache line size).
Change-Id: Idab71a40a660e33259908ccd880e42a880b5ee06
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/11103
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Create a stub of a compression framework where we can have
multiple data blocks per tag entry. Only consecutive blocks
can share a tag as of now.
For each tag entry there can be multiple data blocks. We have
the same number of tags a conventional cache would have, but
we instantiate the maximum number of data blocks (according to
the compression ratio) per tag, to virtually implement
compression without increasing the complexity of the simulator.
Change-Id: I549940c7afb2f744ab293ff8bb283967e7551a11
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/10763
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
This is a workaround for a bug introduced from the change:
59e3585a8 arch-arm: We add PRFM PST instruction for arm
which can cause deadlocks in the memory system.
The design of the classic memory system in gem5 makes the folloing two
assumptions:
* A cache that fetches a block with an intention to modify it, becomes
the point of ordering and therefore commits to respond to any snoop
requests [1].
* A cache that fetches an exclusive copy of the block, does so with
the intention to modify it [2]. Immediately after it receives the
block, it will write to it and mark it as dirty. As the point of
ordering, it responds to any outstanding snoops.
The current implementation of prefetch exclusive request breaks the
second assumption. A cache can fetch an exclusive block without an
immediate intention to modify it. If the block is not modified, it
will not be marked as dirty. However, the cache has committed to
respond to outstanding snoops, and if the block is clean it
won't. This can result in deadlocks where a snoop gets stuck waiting
for responses.
One solution (implemented by this patch) is to unconditionally mark
the block dirty when filling due to a prefetch exclusive request.
This makes the PrefetchExReq behave like a WriteReq. However, as it
may mark as dirty a clean block, it creates the requirement for an
uncessary WritebackDirty in the future. In practice, this shouldn't be
a big problem unless the application is unnecessarily using prefetch
exclusive instructions.
Other solutions, would require deeper changes to the design of the
memory system to handle this properly.
[1]: When a cache commits to respond, it "informs" the xbar/PoC (point
of coherence) and the other caches of its intention to respond. As a
result the request will not be send to the main memory.
[2]: In fact the assumption is that in the needsWritable MSHR there is
at least one WriteReq before any snoops from other caches.
Change-Id: I378d3c0dadf25fc52e430b67102347b44d2f18ea
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/17729
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>
c_j(al) has a special format, called CJ.
The jump offset format is instbits[12:2] --> offset[11|4|9:8|10|6|7|3:1|5]
Currently in decoder.isa, c_j format is JOp, the imm and branchTarget are incorrect
In the execute section (decoder.isa:228), the imm fields is ignored and the offset is calculated correctlly.
As a result, we get decoder flush for each c_j instance
I've added CJOp format in compressed.isa, and use it in execute section.
In addition, c_j is mappped to jal zero, cj_imm, and actually is neither indirect control nor a function call
I fixed the flags accordently.
I'll fix all IsRet, IsCall and IsIndirectControl flags for rest of (c_)jal(r) in my next commit.
I ran coremark -O0 before my fix and I got 37.7% branch miss-rate, after the fix the branch miss-rate is <13%
Change-Id: I608d5894a78a1ebefe36f21e21aaea68b42bccfc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/17808
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Alec Roelke <alec.roelke@gmail.com>
This patch is adding a StreamID tag to any DMA Packet. StreamIDs are
tags which are used by IOMMUs to distinguish between different
devices/functions.
For PCI devices for example, the RID (Pci Bus number, Pci Device
number, Pci Function number) could be stored in the Packet streamID
field.
For the DmaDevice base class, a simple pair of (Sub)StreamIDs has been
provided. This is basically attaching a fixed (decided at python config
time) streamID per device. If a derived device wants to implement a
more elaborate packet tagger (for example if it wants to have more than
one streamID), it needs to pass a different StreamID and SubstreamID to
the DmaPort interface (like dmaAction).
Change-Id: Ia17cf00437f7d3eb79211c1374134b174f90de59
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/16749
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Some methods like groupPriorityMask check for the value of binary point
registers. Those registers have a minimum value. Writing to those
register is taking this into account, but the problem with the minimum
value arises when the value is checked before sw is writing to them.
In this case the minimum value won't be considered if the read is
directly forwarded to the ISA class.
Change-Id: Id432a37f1634b02bc478d65c52ffb88323d4bb77
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18598
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Refactoring the existing in code in smaller methods will be crucial when
adding the ITS module, which is a client for the redistributor class and
which will require it to take different actions depending on the command
it receives from software.
List of methods:
* read/writeEntryLPI
Reading/Writing a byte from the LPI pending table
* isPendingLPI
Checks if the pINTID LPI is set. Knowing if an LPI is set is needed by
the MOVI command, which is transfering the pending state from one
redistributor to the other only if the LPI is pending.
Change-Id: If14b1c28ff7f2aa20b12dcd822bf6a490cbe0270
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18596
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This doesn't need to be plumbed through generic interfaces. If the
function/instruction got more complex in the future (unlikely since
Alpha doesn't really see development these days), it could be moved to
a helper function defined within Alpha files.
Change-Id: Ib746fad7bb13c5cc9c6ee555c3a46ce686771c12
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18433
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
54c77aa055 introduced a bug which manifests as cyclical
dependency on a member initialization for the Process
class.
The current working directory (cwd) parameter is passed into
Process to initialize both the target and host versions of the
cwd. (The target and host versions may differ if the faux
filesystem is used.) The host cwd init invoked methods which
rely on the host cwd already being initialized. To avoid the
bug, the code will now rely on using the targets cwd version,
but will issue checks against the redirect paths.
Change-Id: I4ab644a3e00737dbf249f5d6faf20a26ceb04248
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18448
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Then cast to the ISA specific type when necessary. This removes
(mostly) an ISA specific aspect to some of the interfaces. The ISA
specific version of the kernel stats still needs to be constructed and
stored in a few places which means that kernel_stats.hh still needs to
be a switching arch header, for instance.
In the future, I'd like to make the kernel its own object like the
Process objects in SE mode, and then it would be able to instantiate
and maintain its own stats.
Change-Id: I8309d49019124f6bea1482aaea5b5b34e8c97433
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18429
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
This mechanism had just been plumbed into the regular request_update,
but that doesn't have any thread safety which is the whole point of
async_request_update. This new mechanism puts async update requests
into their own list which is checked any time normal updates happen.
The delta cycle which triggers those updates must happen through some
other means which will usually be ok. The exact timing of the update
is undefined, so it would be legal for it to either not be recognized
before the impending end of the simulation, or for it to get picked up
by subsequent activity. If there isn't subsequent activity but the
simulation also doesn't end, for instance if there are only gem5 events
left, then that update could be lost. That is an unresolved issue.
It would be nice to schedule a "ready" event if async updates were
added which would ensure they wouldn't starve. Unfortunately that
requires the event queue lock, and in practice it's been found that a
systemc process might block, effectively holding the event queue lock,
while it waits for some asyncrhonous update to give it something to do.
This effectively deadlocks the system since the update is blocked on
the lock the main thread holds, and the main thread is blocked waiting
for the update.
Change-Id: I580303db01673faafc2e63545b6a69b3327a521c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18288
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These accessors can be implemented as helper functions within MIPS
without having to plumb them through a bunch of common interfaces.
There are a few problems with the way they were implemented which are
carried forward to this new implementation as well. That includes
hiding the register accesses from the ISA parser and therefore the
CPU's dependency tracking, potentially panicing or accessing a non
existent thread based on a possible set of input values, and modifying
register values even if an instruction is being executed speculatively.
Fixing these problems would be fairly involved and require changing how
dependencies are tracked in all the CPUs so that they can act across
threads, and also how registers are handled in the ISA description
itself.
The original implementation just punted on making this work in CPUs
other than the minor CPU (and potentially one or more CPU models that
were not and/or are not in the code base). Where as that implementation
might have paniced if these methods were called, this will attempt to
work, but may have incorrect behavior based on the limitations
described above. I'd consider this an acceptable tradeoff, at least for
the time being.
Change-Id: I94adceafb9812a8641c76ea3518c3285c31baf51
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18435
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
