#
12684:44ebd2bc020f |
|
27-Mar-2018 |
Daniel R. Carvalho <odanrc@yahoo.com.br> |
mem-cache: ReplacementPolicy specific replacement data
Replacement data is specific for each replacement policy, and thus should be instantiated differently by each policy.
Touch() and reset() do not need to be aware of CacheBlk, as they only update its ReplacementData.
Invalidate() makes replacement policies independent of cache blocks, by removing the awareness of the valid state.
An inheritable base ReplaceableEntry class was created to allow usage of replacement policies with any table-like structure.
Change-Id: I998917d800fa48504ed95abffa2f1b7bfd68522b Reviewed-on: https://gem5-review.googlesource.com/9421 Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
#
12600:e670dd17c8cf |
|
19-Feb-2018 |
Daniel R. Carvalho <odanrc@yahoo.com.br> |
mem-cache: Split array indexing and replacement policies.
Replacement policies (LRU, Random) are currently considered as array indexing methods, but have completely different functionalities:
- Array indexers determine the possible locations for block allocation. This information is used to generate replacement candidates when conflicts happen. - Replacement policies determine which of the replacement candidates should be evicted to make room for new allocations.
For this reason, they were split into different classes. Advantages:
- Easier and more straightforward to implement other replacement policies (RRIP, LFU, ARC, ...) - Allow easier future implementation of cache organization schemes
As now we can't assure the use of sets, the previous way to create a true LRU is not viable. Now a timestamp_bits parameter controls how many bits are dedicated for the timestamp, and a true LRU can be achieved through an infinite number of bits (although a few bits suffice in practice).
Change-Id: I23750db121f1474d17831137e6ff618beb2b3eda Reviewed-on: https://gem5-review.googlesource.com/8501 Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
|