forked from tgrogers/gem5
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README
57 lines (45 loc) · 3.15 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
Cache Replacement policies are critical to the performance of a computer system.
Static Replacement policies like LRU (Least Recently Used) is a popular cache replacement policy
which always assumes that the cache block has a near re-reference interval. As a result, workloads
which have a distant re-reference interval perform badly under LRU. Such workloads usually either
have a mixed access pattern or a working set size which is larger than a cache size. These kinds
of workloads are very common in practice, hence it is essential to predict the re-reference interval
of the newly brought cache block. In this report, we analyze two such replacement policies,
(1) Dynamic Re-Reference Interval Prediction (DRRIP) and (2) Signature Hit Predictor (SHiP).
DRRIP dynamically chooses between SRRIP (Static Re-Reference Interval Prediction) which is a scan
resistant policy and BRRIP (Bimodal Re-Reference Interval Prediction) which is thrash resistant policy.
DRRIP uses a technique named Set-Dueling and dynamically makes a decision to follow one of the two
replacement policies. On the other hand, SHiP monitors the re-reference behaviour of cache lines using
unique signatures and subsequently predicts if the incoming cache line has a distant or an intermediate
re-reference interval. We implement SHiP-Mem which uses memory region signatures to learn the re-reference
behaviours of cachelines associated with that signature. We analyse the effectiveness of the implemented
replacement policies (DRRIP and SHiP-Mem) on SPEC 2006 workloads over the baseline LRU policy.
This is the gem5 simulator.
The main website can be found at http://www.gem5.org
A good starting point is http://www.gem5.org/about, and for
more information about building the simulator and getting started
please see http://www.gem5.org/documentation and
http://www.gem5.org/documentation/learning_gem5/introduction.
To build gem5, you will need the following software: g++ or clang,
Python (gem5 links in the Python interpreter), SCons, SWIG, zlib, m4,
and lastly protobuf if you want trace capture and playback
support. Please see http://www.gem5.org/documentation/general_docs/building
for more details concerning the minimum versions of the aforementioned tools.
Once you have all dependencies resolved, type 'scons
build/<ARCH>/gem5.opt' where ARCH is one of ARM, NULL, MIPS, POWER, SPARC,
or X86. This will build an optimized version of the gem5 binary (gem5.opt)
for the the specified architecture. See
http://www.gem5.org/documentation/general_docs/building for more details and
options.
The basic source release includes these subdirectories:
- configs: example simulation configuration scripts
- ext: less-common external packages needed to build gem5
- src: source code of the gem5 simulator
- system: source for some optional system software for simulated systems
- tests: regression tests
- util: useful utility programs and files
To run full-system simulations, you will need compiled system firmware
(console and PALcode for Alpha), kernel binaries and one or more disk
images.
If you have questions, please send mail to [email protected]
Enjoy using gem5 and please share your modifications and extensions.