more readme improvements

This commit is contained in:
Ciro Santilli 六四事件 法轮功
2020-10-30 00:00:02 +00:00
parent 5c4683d3d3
commit 304bf3dbe9
3 changed files with 0 additions and 169 deletions

View File

@@ -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?