e5187e279a
Currently, the test in realview64-simple-atomic-checkpoint.py runs the default number of checkpoint cycles which is 5. Each of these cycles takes a long time to run (approximately 5 minutes) which makes this test take a long time to run to completion. We would get almost all of the benefit of this test in a fraction of the time if we reduce the number of iterations down to 3. This still has enough iterations to catch bugs which would happen in one, a different class of bugs which happen when checkpointing more than once, and even a third iteration for safety. Because this test is one of the (if not the) most time consuming test in the quick tests, reducing its length will significantly improve turn around time when running all those tests. That is especially valuable when running the tests multiple times to try to iterate on a bug, or when sweeping through a series of changes trying to identify the source of breakages. In cases where we might need to identify failures which don't effect the end product of a series, ie where a problem is introduced and then coincidentally fixed in a later change, this is especially important since every individual change needs to be checked, not just log(n) of the changes like in a binary search. Ideally in the future we will also try to figure out why taking and restoring from checkpoints takes so long so that each iteration of this test is substantially less expensive. If we do that, we could consider increasing the iteration count again. Change-Id: Icfa2a391a4a7457d893f2063fab231d22e572deb Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53123 Maintainer: Bobby Bruce <bbruce@ucdavis.edu> Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
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, 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 these tools. Once you have all dependencies resolved, type 'scons build/<CONFIG>/gem5.opt' where CONFIG is one of the options in build_opts like ARM, NULL, MIPS, POWER, SPARC, X86, Garnet_standalone, etc. This will build an optimized version of the gem5 binary (gem5.opt) with the the specified configuration. See http://www.gem5.org/documentation/general_docs/building for more details and options. The main source tree includes these subdirectories: - build_opts: pre-made default configurations for gem5 - build_tools: tools used internally by gem5's build process. - configs: example simulation configuration scripts - ext: less-common external packages needed to build gem5 - include: include files for use in other programs - site_scons: modular components of the build system - 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 may need compiled system firmware, kernel binaries and one or more disk images, depending on gem5's configuration and what type of workload you're trying to run. Many of those resources can be downloaded from http://resources.gem5.org, and/or from the git repository here: https://gem5.googlesource.com/public/gem5-resources/ If you have questions, please send mail to gem5-users@gem5.org Enjoy using gem5 and please share your modifications and extensions.