From 304bf3dbe9950321ea04b927fc762780e56e991d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ciro=20Santilli=20=E5=85=AD=E5=9B=9B=E4=BA=8B=E4=BB=B6=20?= =?UTF-8?q?=E6=B3=95=E8=BD=AE=E5=8A=9F?= Date: Fri, 30 Oct 2020 00:00:02 +0000 Subject: [PATCH] more readme improvements --- .gitmodules | 3 - README.adoc | 165 ------------------------------------ submodules/parsec-benchmark | 1 - 3 files changed, 169 deletions(-) delete mode 160000 submodules/parsec-benchmark diff --git a/.gitmodules b/.gitmodules index 2aef30d..1c9c96d 100644 --- a/.gitmodules +++ b/.gitmodules @@ -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 diff --git a/README.adoc b/README.adoc index 7975cd7..768e822 100644 --- a/README.adoc +++ b/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: - -* <>, most likely what you want -* <> - -===== 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: - -* <> if the unpacked inputs are large -* <>, 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? diff --git a/submodules/parsec-benchmark b/submodules/parsec-benchmark deleted file mode 160000 index 7b6c9d1..0000000 --- a/submodules/parsec-benchmark +++ /dev/null @@ -1 +0,0 @@ -Subproject commit 7b6c9d1c942014ba4e2233fe0305b2f9d9d3520b