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 resource has been deprecated in favor of 'x86-ubuntu-18.04-img'. In
practise, these are the same resource (i.e., the same disk image), but
we deprecate 'x86-ubuntu-img' as 'x86-ubuntu-18.04-img' is more explicit
on what the disk image contains. Going forward we may want different
disk image resources with different Ubuntu versions, and we want it to
be clear what the user is retrieving.
Change-Id: I06b08e6b65cf431067ffda35ebd10d419068d073
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54583
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
GCN3_X86 and VEGA_X86 can use the same test binaries to run tests for
that build configuration. This adds an option to the nightly and weekly
test scripts to select which GPU ISA to test. By default the GCN3_X86
ISA is tested which was previously the only test. No behavior is changed
from current testing.
Change-Id: Ifedcdea5d7c1c8e9994559a20aea5e1954180772
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54083
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Remove the line "For use for simulation and test purposes only" in files
were AMD is the only copyright holder listed in the header. This happens
to be the case for all files where this line exists, removing it
completely from gem5.
Change-Id: I623f266b002f564301b28774f49081099cfc60fd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53943
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This change removes the code base for SingleChannelMemory and
replaces it with MultiChannelMemory. muli_channel defines all
the classes that were defined by single_channel. Basically any
SingleChannelMemory could be thought of as a MultiChannelMemory
with 1 channel.
Change-Id: If96079d5f77be5a3ba26d2c2ddb98f5c60375cd8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53304
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This test includes,
- A dockerfile creating a Docker image containing SST-Core
and SST-Elements installed. The image also contains the
bbl-busybox-boot-exit binary from gem5-resources.
- A nightly test involving compiling gem5 as a library, and
booting a linux kernel without a disk image using SST where
gem5 TimingSimpleCPU is the CPU core.
Change-Id: I2bf90b4121ed0d38300451648f2e358a7c3fffe2
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52564
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This allows us to set a high number of threads for gem5 compilation
tasks, and a lower number of threads for running gem5. The latter is
more memory intensive and, therefore, we cannot always use the maximum
number of threads in a system.
Change-Id: I699d9f74b21d31841bf31e3589d323b007cb4601
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53483
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Without this verbose flag, there is no information output on the tests
currently running. Output is only given on the pass/fail status of a
test after completion. This is unhelpful if the tests fail due to a
timeout (e.g., a test has stalled).
The '-vv' verbose flags sets up the TestLib package to output when a
test has started execution. This information can help in figuring out
which test caused a timeout event to occur.
Change-Id: I14e6752d40a7c8d7189211584073ba79c88ed7d5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53305
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
In order to fix several regression failures [1] the master/slave
terminology in src/cpu/BaseCPU.py was reintroduced [2].
This patch is addressing the issue by providing 2 different
ways of connecting cpu ports:
*) connectBus: The method assumes an object with a bus interface is
passed as an argument, therefore it tries to bind cpu ports to the
bus.mem_side_ports and bus.cpu_side_ports
*) connectAllPorts: No assumption on the port owning device is made.
The method simply accepts ports as arguments which will be directly
connected to the peer cpu ports
This will be used for example by ruby Sequencers
[1]: https://gem5.atlassian.net/browse/GEM5-775
[2]: https://gem5-review.googlesource.com/c/public/gem5/+/34495
Change-Id: I715ab8471621d6e5eb36731d7eaefbedf9663a71
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52584
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Two tests, one in test_kvm_fork_run.py and another in
test_kvm_cpu_switch.py, were trying to run the MI_Example protocol as
part of the quick/kokoro run. MI_Example requires the building of X86,
though we try to use GCN3_X86 exclusively to avoid compiling an
additional target. As such, these MI_Example tests have been moved to
the long/nightly run.
Change-Id: I3c196e7e336148a1b7a124b5810348a2e587fe24
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52563
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This enables an SE mode execution of binary if added a Board's
superclass.
This has been abstracted from the SimpleBoard.
The 'set_workload' function has been renamed 'set_se_binary_workload'.
This is clearer on its purpose and doesn't overlap with other
'set_workload' functions.
Change-Id: I714425a3b6b98b91e762ad076eba583bc5953ddd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52186
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
This patch moves 'connect_things' to the AbstractBoard constructor,
thereby meaning it does not need to be called directly in gem5
configuration scripts. This method has been changed to private as a
result.
As boards that inherit from AbstractBoard require certain things to be
setup prior to `connect_things` being called, a new abstract function,
`_setup_board` has been created. This is called in the AbstractBoard
constructor before `connect_things` and can be overridden by boards to
setup board properties as required.
Change-Id: I558a4321b850a6b19e20b7d56d0bcae5805114b6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52184
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The override parameter in the constructor has been renamed to to
'download_md5_mismatch'. This makes the purpose of this parameter
clearer.
The default value has been changed from False to True. We found in most
cases we want to re-download files if the md5 values have changes. Not
wanting to do so is the corner case. This allows us to remove a lot of
parameters from test and example scripts, included in this patch.
Change-Id: I99fc7743f5adf78bf6f4f8efc6222e6df83ac6da
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52086
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The purpose of this class is to:
* Create a standard way to set a typical kernel/disk image workload.
* Cleans up the manner in which readfile values/contents are set.
* Allows a user to specify their own kernel arguments, but still sets
sensible defaults.
As of this commit, this interface has been added to the X86Board and the
RISCVBoard.
Change-Id: I34f4c2b829f1ae5c1cae12039436cbb345a89d09
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51949
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
There has been some confusion about usage of 'Optional'. In some areas
of the codebase it was assumed this specifies an optional parameter
(i.e., one which may or may not set, as it has a default value). This is
incorrect. 'Optional[<type>]' is shorthand for 'Union[<type>, None]',
i.e., it is used to state the value may be 'None'. This patch corrects
this throughout the gem5 codebase.
Change-Id: I77a6708dee448e8480870d073e128aed3d6ae904
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52143
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The GPU models support a simple register allocation policy (1 WF/CU at a
time) and a dynamic register allocation policy (up to max WF/CU at a
time). By default, the simple policy is used. However, the dynamic
policy is much more realistic relative to real hardware and thus much
more important to ensure it works in the regressions. This commit
updates the nightly and weekly regressions accordingly to run the
dynamic register allocation policy.
Change-Id: Id263d3d5e19e4ff47f0eb6d9b08cbafdf2177fb9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52163
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Add the Pannotia benchmarks to the weekly regression suite. These
applications do a good job of testing the GPU support for irregular
access patterns of various kinds. All inputs have been sized to use
relatively small graphs to avoid increasing runtime too much. However,
even with small input sizes Pannotia does run for a while.
Note that the Pannotia benchmarks also use m5ops in them. Thus, this
commit also adds support into the weekly regression for compiling the
m5ops (for x86, since that is what the GPU model assumes for the CPU).
Change-Id: I1f68b02b38ff24505a2894694b7544977024f8fa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51968
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
66a056b8 changed the weekly regression to use a single docker for
all GPU tests, to reduce how many times gem5 needed to be compiled.
However, in my local testing of that patch, gem5-resources was not
deleted until after the docker was created -- which causes a problem
when gem5-resources does not exist already from a prior run, since
the creation of the dockerfile requires it for HACC. This commit
fixes this problem by moving the pull of gem5-resources to be before
anything else related to the GPU happens.
Change-Id: I006860204d03807d95628aa5dcf6e82d202fef9c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51907
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This tests forking gem5 and simulating the child with a different cpu.
The test boots linux with the KVM cpu and then forks gem5. Each child
simulation switches to the specified cpu and simulates to completion
while the parents waits for the children to finish before also
simulating to completion.
Change-Id: I68d7515bf125c855eefc62ba4798cd7c745ef2b0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50467
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
