mirror of
https://github.com/cirosantilli/linux-kernel-module-cheat.git
synced 2026-01-23 10:15:57 +01:00
more readme improvements
This commit is contained in:
3
.gitmodules
vendored
3
.gitmodules
vendored
@@ -33,9 +33,6 @@
|
||||
[submodule "submodules/linux"]
|
||||
path = submodules/linux
|
||||
url = https://github.com/cirosantilli/linux
|
||||
[submodule "submodules/parsec-benchmark"]
|
||||
path = submodules/parsec-benchmark
|
||||
url = https://github.com/cirosantilli/parsec-benchmark
|
||||
[submodule "submodules/qemu"]
|
||||
path = submodules/qemu
|
||||
url = https://github.com/cirosantilli/qemu
|
||||
|
||||
165
README.adoc
165
README.adoc
@@ -19581,8 +19581,6 @@ Documented at: https://github.com/buildroot/buildroot/blob/2017.08/docs/manual/r
|
||||
|
||||
Also mentioned at: https://stackoverflow.com/questions/47320800/how-to-clean-only-target-in-buildroot
|
||||
|
||||
See this for a sample manual workaround: xref:parsec-uninstall[xrefstyle=full].
|
||||
|
||||
[[br2-target-rootfs-ext2-size]]
|
||||
=== BR2_TARGET_ROOTFS_EXT2_SIZE
|
||||
|
||||
@@ -21198,169 +21196,6 @@ TODO also consider the following:
|
||||
* http://www.cs.virginia.edu/stream/ref.html STREAM memory bandwidth benchmarks.
|
||||
* https://github.com/kozyraki/stamp transactional memory benchmarks
|
||||
|
||||
==== PARSEC benchmark
|
||||
|
||||
We have ported parts of the http://parsec.cs.princeton.edu[PARSEC benchmark] for cross compilation at: https://github.com/cirosantilli/parsec-benchmark See the documentation on that repo to find out which benchmarks have been ported. Some of the benchmarks were are segfaulting, they are documented in that repo.
|
||||
|
||||
There are two ways to run PARSEC with this repo:
|
||||
|
||||
* <<parsec-benchmark-without-parsecmgmt,without `pasecmgmt`>>, most likely what you want
|
||||
* <<parsec-benchmark-with-parsecmgmt,with `pasecmgmt`>>
|
||||
|
||||
===== PARSEC benchmark without parsecmgmt
|
||||
|
||||
....
|
||||
./build --arch arm --download-dependencies gem5-buildroot parsec-benchmark
|
||||
./build-buildroot --arch arm --config 'BR2_PACKAGE_PARSEC_BENCHMARK=y'
|
||||
./run --arch arm --emulator gem5
|
||||
....
|
||||
|
||||
Once inside the guest, launch one of the `test` input sized benchmarks manually as in:
|
||||
|
||||
....
|
||||
cd /parsec/ext/splash2x/apps/fmm/run
|
||||
../inst/arm-linux.gcc/bin/fmm 1 < input_1
|
||||
....
|
||||
|
||||
To find run out how to run many of the benchmarks, have a look at the `test.sh` script of the `parse-benchmark` repo.
|
||||
|
||||
From the guest, you can also run it as:
|
||||
|
||||
....
|
||||
cd /parsec
|
||||
./test.sh
|
||||
....
|
||||
|
||||
but this might be a bit time consuming in gem5.
|
||||
|
||||
===== PARSEC change the input size
|
||||
|
||||
Running a benchmark of a size different than `test`, e.g. `simsmall`, requires a rebuild with:
|
||||
|
||||
....
|
||||
./build-buildroot \
|
||||
--arch arm \
|
||||
--config 'BR2_PACKAGE_PARSEC_BENCHMARK=y' \
|
||||
--config 'BR2_PACKAGE_PARSEC_BENCHMARK_INPUT_SIZE="simsmall"' \
|
||||
-- parsec_benchmark-reconfigure \
|
||||
;
|
||||
....
|
||||
|
||||
Large input may also require tweaking:
|
||||
|
||||
* <<br2-target-rootfs-ext2-size>> if the unpacked inputs are large
|
||||
* <<memory-size>>, unless you want to meet the OOM killer, which is admittedly kind of fun
|
||||
|
||||
`test.sh` only contains the run commands for the `test` size, and cannot be used for `simsmall`.
|
||||
|
||||
The easiest thing to do, is to https://superuser.com/questions/231002/how-can-i-search-within-the-output-buffer-of-a-tmux-shell/1253137#1253137[scroll up on the host shell] after the build, and look for a line of type:
|
||||
|
||||
....
|
||||
Running /root/linux-kernel-module-cheat/out/aarch64/buildroot/build/parsec-benchmark-custom/ext/splash2x/apps/ocean_ncp/inst/aarch64-linux.gcc/bin/ocean_ncp -n2050 -p1 -e1e-07 -r20000 -t28800
|
||||
....
|
||||
|
||||
and then tweak the command found in `test.sh` accordingly.
|
||||
|
||||
Yes, we do run the benchmarks on host just to unpack / generate inputs. They are expected fail to run since they were build for the guest instead of host, including for x86_64 guest which has a different interpreter than the host's (see `file myexecutable`).
|
||||
|
||||
The rebuild is required because we unpack input files on the host.
|
||||
|
||||
Separating input sizes also allows to create smaller images when only running the smaller benchmarks.
|
||||
|
||||
This limitation exists because `parsecmgmt` generates the input files just before running via the Bash scripts, but we can't run `parsecmgmt` on gem5 as it is too slow!
|
||||
|
||||
One option would be to do that inside the guest with QEMU.
|
||||
|
||||
Also, we can't generate all input sizes at once, because many of them have the same name and would overwrite one another...
|
||||
|
||||
PARSEC simply wasn't designed with non native machines in mind...
|
||||
|
||||
===== PARSEC benchmark with parsecmgmt
|
||||
|
||||
Most users won't want to use this method because:
|
||||
|
||||
* running the `parsecmgmt` Bash scripts takes forever before it ever starts running the actual benchmarks on gem5
|
||||
+
|
||||
Running on QEMU is feasible, but not the main use case, since QEMU cannot be used for performance measurements
|
||||
* it requires putting the full `.tar` inputs on the guest, which makes the image twice as large (1x for the `.tar`, 1x for the unpacked input files)
|
||||
|
||||
It would be awesome if it were possible to use this method, since this is what Parsec supports officially, and so:
|
||||
|
||||
* you don't have to dig into what raw command to run
|
||||
* there is an easy way to run all the benchmarks in one go to test them out
|
||||
* you can just run any of the benchmarks that you want
|
||||
|
||||
but it simply is not feasible in gem5 because it takes too long.
|
||||
|
||||
If you still want to run this, try it out with:
|
||||
|
||||
....
|
||||
./build-buildroot \
|
||||
--arch aarch64 \
|
||||
--config 'BR2_PACKAGE_PARSEC_BENCHMARK=y' \
|
||||
--config 'BR2_PACKAGE_PARSEC_BENCHMARK_PARSECMGMT=y' \
|
||||
--config 'BR2_TARGET_ROOTFS_EXT2_SIZE="3G"' \
|
||||
-- parsec_benchmark-reconfigure \
|
||||
;
|
||||
....
|
||||
|
||||
And then you can run it just as you would on the host:
|
||||
|
||||
....
|
||||
cd /parsec/
|
||||
bash
|
||||
. env.sh
|
||||
parsecmgmt -a run -p splash2x.fmm -i test
|
||||
....
|
||||
|
||||
===== PARSEC uninstall
|
||||
|
||||
If you want to remove PARSEC later, Buildroot doesn't provide an automated package removal mechanism as mentioned at: xref:remove-buildroot-packages[xrefstyle=full], but the following procedure should be satisfactory:
|
||||
|
||||
....
|
||||
rm -rf \
|
||||
"$(./getvar buildroot_download_dir)"/parsec-* \
|
||||
"$(./getvar buildroot_build_dir)"/build/parsec-* \
|
||||
"$(./getvar buildroot_build_dir)"/build/packages-file-list.txt \
|
||||
"$(./getvar buildroot_build_dir)"/images/rootfs.* \
|
||||
"$(./getvar buildroot_build_dir)"/target/parsec-* \
|
||||
;
|
||||
./build-buildroot --arch arm
|
||||
....
|
||||
|
||||
===== PARSEC benchmark hacking
|
||||
|
||||
If you end up going inside link:submodules/parsec-benchmark[] to hack up the benchmark (you will!), these tips will be helpful.
|
||||
|
||||
Buildroot was not designed to deal with large images, and currently cross rebuilds are a bit slow, due to some image generation and validation steps.
|
||||
|
||||
A few workarounds are:
|
||||
|
||||
* develop in host first as much as you can. Our PARSEC fork supports it.
|
||||
+
|
||||
If you do this, don't forget to do a:
|
||||
+
|
||||
....
|
||||
cd "$(./getvar parsec_source_dir)"
|
||||
git clean -xdf .
|
||||
....
|
||||
before going for the cross compile build.
|
||||
+
|
||||
* patch Buildroot to work well, and keep cross compiling all the way. This should be totally viable, and we should do it.
|
||||
+
|
||||
Don't forget to explicitly rebuild PARSEC with:
|
||||
+
|
||||
....
|
||||
./build-buildroot \
|
||||
--arch arm \
|
||||
--config 'BR2_PACKAGE_PARSEC_BENCHMARK=y' \
|
||||
-- parsec_benchmark-reconfigure \
|
||||
;
|
||||
....
|
||||
+
|
||||
You may also want to test if your patches are still functionally correct inside of QEMU first, which is a faster emulator.
|
||||
* sell your soul, and compile natively inside the guest. We won't do this, not only because it is evil, but also because Buildroot explicitly does not support it: https://buildroot.org/downloads/manual/manual.html#faq-no-compiler-on-target ARM employees have been known to do this: https://github.com/arm-university/arm-gem5-rsk/blob/aa3b51b175a0f3b6e75c9c856092ae0c8f2a7cdc/parsec_patches/qemu-patch.diff
|
||||
|
||||
==== Microbenchmarks
|
||||
|
||||
It eventually has to come to that, hasn't it?
|
||||
|
||||
Submodule submodules/parsec-benchmark deleted from 7b6c9d1c94
Reference in New Issue
Block a user