Implementation of a generic frequency-based sampling
compressor. The compressor goes through a sampling stage,
where no compression is done, and the values are simply
sampled for their frequencies. Then, after enough samples
have been taken, the compressor starts generating
compressed data.
Compression works by comparing chunks to the table of
most frequent values. In theory, a chunk that is present
in the frequency table has its value replaced by the
index of its respective entry in the table. In practice,
the value itself is stored because there is no straight-
forward way to acquire an index from an entry.
Finally, the index can be encoded so that the values
with highest frequency have smaller codeword representation.
Its Huffman coupling can be used similar to the approach
taken in "SC 2 : A Statistical Compression Cache Scheme".
Change-Id: Iae0ebda08e8c08f3b62930fd0fb7e818fd0d141f
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37335
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
For some segments, there are two base registers. One is the
architecturally visible base, and the other is the effective base used
when actually referencing memory relative to that segment. The process
initialization code was setting the architecturally visible base,
presumably because that's the value used by KVM, but was setting the
effective base to zero.
Change-Id: I06e079f24fa63f0051268437bf00c14578f62612
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38488
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When a gem5 op is triggered using a KVM MMIO exit event, the PC has
already been advanced beyond the offending instruction. Normally when
a system call or gem5 op is triggered, the PC has not advanced because
the instruction hasn't actually finished executing. This means that if
a gem5 op, and by extension a system call in SE mode, want to advance
the PC to the instruction after the gem5 op, they have to check whether
they were triggered from KVM.
To avoid having to special case these sorts of situations (currently
only in the clone system call), we can have the code which dispatches to
gem5 ops from KVM adjust the next PC so that it points to what the
current PC is. That way the PC can be advanced unconditionally, and will
point to the instruction after the one that triggered the call.
To be fully consistent, we would also need to adjust the current PC.
That would be non-trivial since we'd have to figure out where the
current instruction started, and that may not even be possible to
unambiguously determine given x86's instruction structure. Then we would
also need to restore the original PC to avoid confusing KVM.
Change-Id: I9ef90b2df8e27334dedc25c59eb45757f7220eea
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38486
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These pseudo insts are less useful outside of full system, but they
should all still work. Removing this check makes it possible to, for
instance, test them in syscall emulation mode, and removes another
difference between the two styles of simulation.
Change-Id: Ia7d29bfc6f7c5c236045d151930fc171a6966799
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38485
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is the official scons way to check for things on the system. This
adds two custom checks, one for java packages and one for pkg-config
packages. This change also adds a check for the org.junit java package
which is/will be used for a test for the java wrapper.
Change-Id: I59ca559f257a4c671e9b72a50b5635b5eb61ee69
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28180
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Installing the term utility within the host filesystem is an unlikely
scenario. Most times, the utility will be used in place or trivially
copied to a local directory within the PATH.
Furthermore, the install target hardcoded a privileged installation,
which is a non-standard and insecure technique.
Change-Id: I1592a304017c6b24a9421aa353229fb5a5baae43
Signed-off-by: Adrian Herrera <adrian.herrera@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38415
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 following changes were made:
- Improve the wording of comments in the Python files and of the
documentation in the README file.
- Add 10 seconds to the query age so that the bot wouldn't miss
any new changes that could be missed due to time difference between
the Gerrit server and the bot.
Change-Id: Ic75f9572653a248230a8b4b0bd360a8d22efd371
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38155
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Input ports can specify a custom handler that is called
on resource stalls. The handler should return 'true' to
indicate the stall was handled and new messages from that
queue can be processed on that cycle. When it returns
'false' or no handler is defined, a resource stall is
generated.
Handlers are defined using the 'rsc_stall_handler' (for
resource stalls) and the 'prot_stall_handler' (for
protocol stalls) parameters. For example:
in_port(mandatory_in, RubyRequest, mandatoryQueue,
rsc_stall_handler=mandatory_in_stall_handler) {
...
}
bool mandatory_in_stall_handler() {
// Do something here to handle the stall !
return true;
// or return false if we don't want to do anything
}
Note: this patch required a change to the generate()
functions interface in the SLICC compiler, so we
could propagate a reference to the in_port to the
appropriate generate() functions. The updated interface
allows passing and forwarding of keyword arguments.
Change-Id: I3481d130d5eb411e6760a54d098d3da5de511c86
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31265
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 patch updates Ruby configuration scripts to use the functions
defined in the RubySequencer python object to connect to cpu ports.
Only the protocol-agnostic scripts were updated. Scripts that assume
a specific protocol (e.g. configs/example/apu_se.py, gpu tests, etc)
and scripts in which the obj connected to the RubySequencer is not a
BaseCPU (e.g. the tests scripts) were not changed as they require a
non-standard port wireup.
Change-Id: I1e931ff0fc93f393cb36fbb8769ea4b48e1a1e86
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31418
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Added functions for connecting the sequencer and cpu ports.
Using these functions instead of wiring up the ports directly allow
protocols to provide specialized sequencer implementations. For
instance, connecting the cpu icache_port and dcache_port to
different sequencer ports or to different sequencers.
A follow-up patch will update the configurations to use these
functions.
Change-Id: I2d8db8bbfb05c731c0e549f482a9ab93f341474b
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31417
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These tests don't run reliably right now for a few reasons, including
problems with QEMU, and apparently inaccurate information from g++-s
--print-sysroot option.
This may be revisited in the future if those problems can be sorted out.
For now, avoid tripping up new people who won't know to (or how to) work
around those sorts of errors.
Change-Id: Ide42e6c6b27159ff146b8495ae568d1fd377f4f4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28179
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The java wrapper which provides access to the gem5 ops is implemented
using JNI in a .so file which needs to be loaded before the class can be
used. Rather than expecting the caller to do that, we can use a static
block in the class definition. We know that will be called at the right
time, and it's one less detail (arguably an implementation detail) that
the caller won't have to worry about.
Change-Id: I2b4b18ebb12030ea6f4e6463c6cd512afed74cfd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28177
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Rather than use a top level package of jni which is generic, switch to a
top level package of "gem5". With that prefix, call the actual class
Ops, which is capitalized according to Java tradition and also
unambiguous given its package name.
Also move the java class definition and c JNI implementation into a java
subdir to keep it all together. The java related output will now be in
out/java for the same reason.
Change-Id: Ia0468d2edbcffe87a62022898f867ae391adc94c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28176
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Like gem5's own verbose scons flag, when this isn't provided, the output
is very brief and just shows what is being built and by what type of
process. When it is provided, the full command lines are printed.
This is less fancy than the version gem5 has, but I didn't want to
duplicate all that code. We should find a way to share that and other
functionality between different sets of scons scripts.
Change-Id: Id9973b57a1270ec8b364efd2aa67d49b0fb82a9d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27756
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This may be directly in the case of native tests, or through a user
level QEMU binary for non-native tests. scons is smart enough to expect
to be able to run native tests always, and non-native tests only if a
qemu binary has been found.
To tell scons to run tests in a particular category, you can use a
command of this form:
scons build/[category]/test/
where category is either an "abi" like sparc or x86, or "native" for
tests which don't do anything target specific and so can be run on the
host.
There will be two directories under .../tests, "bin" and "result". "bin"
is where the test binaries themselves will be built, and "result" is for
the results of running those binaries.
Change-Id: I6450ab4a97169f8a01292d946bfac18008b0430c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27752
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
When the result is returned to the caller from the pseudoInst dispatch
function, the default behavior is to not store that value using the
guestABI mechanism. In the x86 definition, I accidentally used this
version but then didn't store the result manually. The fix should simply
be to not return the result to the instruction definition and to let the
guestABI mechanism handle everything normally.
Change-Id: Ib69f266ad6314032622e5d8d69e9ff114c62657a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38195
Reviewed-by: Daniel Gerzhoy <daniel.gerzhoy@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously, we were using ROCm 1.6.2 as there were issues with some of
the machine learning applications that weren't present on 1.6.2.
However, after re-running them we've found that they, and all other
applications previously tested, run to completion.
Additionally, there have been patches to enable BLIT kernels which made
it so we no longer need to build HIP and MIOpen differently for APU and
DGPU code. This allows us to install HIP directly from the .deb packages
instead of from source. Installing from the .deb packages also avoid the
hipDeviceSynchronize() bug. Finally, this makes it so most GPU programs
can be run as-is without modifications to remove hipMalloc/hipMemcpy
calls as was done previously.
Change-Id: Ic61b09ed200b19f759d891487cde874abd607537
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37675
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
