3rd-party/linux-kernel-module-cheat
1
0
Fork 0
mirror of https://github.com/cirosantilli/linux-kernel-module-cheat.git synced 2026-01-28 04:24:26 +01:00
Code Issues Releases Wiki Activity

gem5: more Ruby information

Browse Source
This commit is contained in:
Ciro Santilli 六四事件 法轮功
2020-02-23 00:00:00 +00:00
parent 7fbce888cf
commit 20addbcd66
1 changed files with 63 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

72
README.adoc
View File

@@ -12425,20 +12425,29 @@ Direct leak of 2928 byte(s) in 43 object(s) allocated from:
Direct leak of 2002 byte(s) in 3 object(s) allocated from: Direct leak of 2002 byte(s) in 3 object(s) allocated from:
#0 0x7ff039804448 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c448) #0 0x7ff039804448 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c448)
#1 0x7ff0394fd813 in PyString_FromStringAndSize ../Objects/stringobject.c:88 #1 0x7ff0394fd813 in PyString_FromStringAndSize ../Objects/stringobject.c:88
#2 0x7ff0394fd813 in PyString_FromStringAndSize ../Objects/stringobject.c:57 Direct leak of 40 byte(s) in 2 object(s) allocated from: #0 0x7ff039804448 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c448) #2 0x7ff0394fd813 in PyString_FromStringAndSize ../Objects/stringobject.c:
Direct leak of 40 byte(s) in 2 object(s) allocated from
#0 0x7ff039804448 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c448)
#1 0x7ff03951ea4b in PyList_New ../Objects/listobject.c:152 #1 0x7ff03951ea4b in PyList_New ../Objects/listobject.c:152
Indirect leak of 10384 byte(s) in 11 object(s) allocated from: #0 0x7ff039804448 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c448) #1 0x7ff03945e40d in _PyObject_GC_Malloc ../Modules/gcmodule.c:1499 #2 0x7ff03945e40d in _PyObject_GC_Malloc ../Modules/gcmodule.c:1493 Indirect leak of 10384 byte(s) in 11 object(s) allocated from
#0 0x7ff039804448 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c448
#1 0x7ff03945e40d in _PyObject_GC_Malloc ../Modules/gcmodule.c:
#2 0x7ff03945e40d in _PyObject_GC_Malloc ../Modules/gcmodule.c:1493
Indirect leak of 4089 byte(s) in 6 object(s) allocated from: Indirect leak of 4089 byte(s) in 6 object(s) allocated from:
#0 0x7ff039804448 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c448) #0 0x7ff039804448 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c448)
#1 0x7ff0394fd648 in PyString_FromString ../Objects/stringobject.c:143 #1 0x7ff0394fd648 in PyString_FromString ../Objects/stringobject.c:143
Indirect leak of 2090 byte(s) in 3 object(s) allocated from: Indirect leak of 2090 byte(s) in 3 object(s) allocated from:
#0 0x7ff039804448 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c448) #1 0x7ff0394eb36f in type_new ../Objects/typeobject.c:2421 #2 0x7ff0394eb36f in type_new ../Objects/typeobject.c:2094 #0 0x7ff039804448 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c448
#1 0x7ff0394eb36f in type_new ../Objects/typeobject.c:
#2 0x7ff0394eb36f in type_new ../Objects/typeobject.c:2094
Indirect leak of 1346 byte(s) in 2 object(s) allocated from: Indirect leak of 1346 byte(s) in 2 object(s) allocated from:
#0 0x7ff039804448 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c448) #0 0x7ff039804448 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c448)
#1 0x7ff0394fd813 in PyString_FromStringAndSize ../Objects/stringobject.c:88 #2 0x7ff0394fd813 in PyString_FromStringAndSize ../Objects/stringobject.c:57 SUMMARY: AddressSanitizer: 418319 byte(s) leaked in 203 allocation(s). #1 0x7ff0394fd813 in PyString_FromStringAndSize ../Objects/stringobject.c:
#2 0x7ff0394fd813 in PyString_FromStringAndSize ../Objects/stringobject.c:
SUMMARY: AddressSanitizer: 418319 byte(s) leaked in 203 allocation(s).
.... ....
From the message, this appears however to be a Python / pyenv11 bug however and not in gem5 specifically. I think it worked when I tried it in the past in an older gem5 / Ubuntu. From the message, this appears however to be a Python / pyenv11 bug however and not in gem5 specifically. I think it worked when I tried it in the past in an older gem5 / Ubuntu.
@@ -12447,11 +12456,31 @@ From the message, this appears however to be a Python / pyenv11 bug however and
==== gem5 Ruby build ==== gem5 Ruby build
Ruby is a system that includes the SLICC domain specific language to describe memory systems: http://gem5.org/Ruby gem5 has two types of memory system:
* the classic memory system, which is used by default
* the Ruby memory system
The Ruby memory system includes the SLICC domain specific language to describe memory systems: http://gem5.org/Ruby
It seems to have usage outside of gem5, but the naming overload with the link:https://en.wikipedia.org/wiki/Ruby_(programming_language)[Ruby programming language], which also has link:https://thoughtbot.com/blog/writing-a-domain-specific-language-in-ruby[domain specific languages] as a concept, makes it impossible to google anything about it! It seems to have usage outside of gem5, but the naming overload with the link:https://en.wikipedia.org/wiki/Ruby_(programming_language)[Ruby programming language], which also has link:https://thoughtbot.com/blog/writing-a-domain-specific-language-in-ruby[domain specific languages] as a concept, makes it impossible to google anything about it!
Ruby is activated at compile time with the `PROTOCOL` flag, which specifies the desired memory system time. Since it is not the default, Ruby is generally less stable that the classic memory model. However, because it allows describing a wide variety of important coherency protocols, while the classic system only describes a single protocol, Ruby is very importanonly describes a single protocol, Ruby is a very important feature of gem5.
Ruby support must be enabled at compile time with the `scons PROTOCOL=` flag, which compiles support for the desired memory system type.
Note however that most ISAs already implicitly set `PROTOCOL` via the `build_opts/` directory, e.g. `build_opts/ARM` contains:
....
PROTOCOL = 'MOESI_CMP_directory'
....
and therefore ARM already compiles `MOESI_CMP_directory` by default.
Then, with `fs.py` and `se.py`, you can choose to use either the classic or built-in ruby system at runtime with the `--ruby` option:
* if `--ruby` is given, use the ruby memory system
* otherwise, use the classic memory system
For example, to use a two level https://en.wikipedia.org/wiki/MESI_protocol[MESI] https://en.wikipedia.org/wiki/Cache_coherence[cache coherence protocol], we can do: For example, to use a two level https://en.wikipedia.org/wiki/MESI_protocol[MESI] https://en.wikipedia.org/wiki/Cache_coherence[cache coherence protocol], we can do:
@@ -12468,9 +12497,7 @@ and during build we see a humongous line of type:
which shows that dozens of C++ files are being generated from Ruby SLICC. which shows that dozens of C++ files are being generated from Ruby SLICC.
TODO observe it doing something during a run. The relevant Ruby source files live in the source tree under:
The relevant source files live in the source tree under:
.... ....
src/mem/protocol/MESI_Two_Level* src/mem/protocol/MESI_Two_Level*
@@ -12484,6 +12511,33 @@ xdg-open "$(./getvar --arch aarch64 --gem5-build-id ruby gem5_build_build_dir)/A
A minimized ruby config which was not merged upstream can be found for study at: https://gem5-review.googlesource.com/c/public/gem5/+/13599/1 A minimized ruby config which was not merged upstream can be found for study at: https://gem5-review.googlesource.com/c/public/gem5/+/13599/1
One easy way to see that Ruby is being used without understanding it in detail is to <<gem5-tracing,enable some logging>>:
....
./run \
--arch aarch64 \
--emulator gem5 \
--gem5-worktree master \
--userland userland/arch/aarch64/freestanding/linux/hello.S \
--static \
--trace ExecAll,FmtFlag,Ruby,XBar \
-- \
--ruby \
;
cat "$(./getvar --arch aarch64 --emulator gem5 trace_txt_file)"
....
Then:
* when the `--ruby` flag is given, we see a gazillion Ruby related messages prefixed e.g. by `RubyPort:`.
+
We also observe from `ExecEnable` lines that instruction timing is not simple anymore, so the memory system must have latencies
* without `--ruby`, we instead see `XBar` (Coherent Crossbar) related messages such as `CoherentXBar:`, which I believe is the more precise name for the memory model that the classic memory system uses
Certain features may not work in Ruby. For example, <<gem5-checkpoint>> creation is only possible in Ruby protocols that support flush, which is the case for `PROTOCOL=MOESI_hammer` but not `PROTOCOL=MESI_Three_Level`: https://www.mail-archive.com/gem5-users@gem5.org/msg17418.html
Tested in gem5 d7d9bc240615625141cd6feddbadd392457e49eb.
==== gem5 Python 3 build ==== gem5 Python 3 build
Python 3 support was mostly added in 2019 Q3 at arounda347a1a68b8a6e370334be3a1d2d66675891e0f1 but remained buggy for some time afterwards. Python 3 support was mostly added in 2019 Q3 at arounda347a1a68b8a6e370334be3a1d2d66675891e0f1 but remained buggy for some time afterwards.