changeset 5c2c4195b839 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=5c2c4195b839
description:
mem: Squash prefetch requests from downstream caches
This patch squashes prefetch requests from downstream caches,
so that they do not steal cachelines
Hi All,
Recently I have written a patch that removes templating from the o3 cpu.
In general templating in o3 makes the code significantly more verbose,
adds compile time overheads, and doesn't actually benefit performance. The
templating is largely pointless as 1) there aren't multiple versions
names as typedefs in the relevant header files.
//Andreas
On 2014-05-13 18:23, Mitch Hayenga via gem5-dev wrote:
Hi All,
Recently I have written a patch that removes templating from the o3
cpu.
In general templating in o3 makes the code significantly more
On June 20, 2014, 2:36 a.m., Steve Reinhardt wrote:
Why is Addr being parsed using toMemorySize() in the first place? That
seems wrong. At least some of the places Addr is used with a size (like
RealView.max_mem_size), I think the problem is that the param should really
be a
changeset 0edd36ea6130 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=0edd36ea6130
description:
ext: clang fix for flexible array members
Changes how flexible array members are defined so clang does not error
out during compilation.
diffstat:
Hi,
I'm the one who wrote this patch.
** The opening comment in the patch states that it is trying to do
twothings. I would suggest that we split the patch.*
Related code was already being changed by this patch, and going out of the
way to handle blocked and deferred memory instructions
On Aug. 19, 2014, 5:11 p.m., Nilay Vaish wrote:
src/cpu/o3/inst_queue.hh, line 322
http://reviews.gem5.org/r/2332/diff/1/?file=40490#file40490line322
I think we need better differentiation between this list and the one
declared after it.
On further reading, it seems
changeset b7715fb7cf9f in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=b7715fb7cf9f
description:
mips: Fix RLIMIT_RSS naming
MIPS defined RLIMIT_RSS in a way that could cause a naming conflict with
RLIMIT_RSS from the host system. Broke clang+MacOS
changeset 5b6279635c49 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=5b6279635c49
description:
cpu: Change writeback modeling for outstanding instructions
As highlighed on the mailing list gem5's writeback modeling can impact
performance. This
changeset 19f5df7ac6a1 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=19f5df7ac6a1
description:
config: Change parsing of Addr so hex values work from scripts
When passed from a configuration script with a hexadecimal value (like
0x8000), gem5
changeset 72890a571a7b in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=72890a571a7b
description:
dev: Avoid invalid sized reads in PL390 with DPRINTF enabled
The first DPRINTF() in PL390::writeDistributor always read a uint32_t,
though a
packet may
changeset 43516d8eabe9 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=43516d8eabe9
description:
arch: Properly guess OpClass from optional StaticInst flags
isa_parser.py guesses the OpClass if none were given based upon the
StaticInst
flags. The
changeset ed05298e8566 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=ed05298e8566
description:
cpu: Fix SMT scheduling issue with the O3 cpu
The o3 cpu could attempt to schedule inactive threads under round-robin
SMT
mode.
This is because
changeset 12e3be8203a5 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=12e3be8203a5
description:
cpu: Add a fetch queue to the o3 cpu
This patch adds a fetch queue that sits between fetch and decode to the
o3 cpu. This effectively decouples fetch
changeset 867b536a68be in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=867b536a68be
description:
cpu: Fix o3 front-end pipeline interlock behavior
The o3 pipeline interlock/stall logic is incorrect. o3 unnecessicarily
stalled
fetch and decode due to
changeset 40d24a672351 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=40d24a672351
description:
cpu: Fix o3 drain bug
For X86, the o3 CPU would get stuck with the commit stage not being
drained if an interrupt arrived while drain was pending.
changeset 53278be85b40 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=53278be85b40
description:
arm: Fix v8 neon latency issue for loads/stores
Neon memory ops that operate on multiple registers currently have very
poor
performance because of
changeset 0b4d10f53c2d in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=0b4d10f53c2d
description:
x86: Flag instructions that call suspend as IsQuiesce
The o3 cpu relies upon instructions that suspend a thread context being
flagged as IsQuiesce. If
changeset 6be8945d226b in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=6be8945d226b
description:
cpu: Fix cache blocked load behavior in o3 cpu
This patch fixes the load blocked/replay mechanism in the o3 cpu.
Rather than
flushing the entire
changeset 5e424aa952c5 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=5e424aa952c5
description:
arm: Mark v7 cbz instructions as direct branches
v7 cbz/cbnz instructions were improperly marked as indirect branches.
diffstat:
changeset 1ba825974ee6 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=1ba825974ee6
description:
cpu: Fix o3 quiesce fetch bug
O3 is supposed to stop fetching instructions once a quiesce is
encountered.
However due to a bug, it would continue
changeset d96b61d843b2 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=d96b61d843b2
description:
arm: Make memory ops work on 64bit/128-bit quantities
Multiple instructions assume only 32-bit load operations are available,
this patch increases load
A bug was recently found in the bimodal predictor. If you are still
looking at this, you might want to try a new checkout. Hope this helps.
On Wed, Jul 2, 2014 at 4:52 PM, Zi Yan via gem5-dev gem5-dev@gem5.org
wrote:
I get 5 100-million-instruction simpoints for each benchmark in
SPEC CPU
changeset c870b43d2ba6 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=c870b43d2ba6
description:
cpu: Only iterate over possible threads on the o3 cpu
Some places in O3 always iterated over Impl::MaxThreads even if a CPU
had
fewer threads. This
changeset 452a5f178ec5 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=452a5f178ec5
description:
mem: Remove the GHB prefetcher from the source tree
There are two primary issues with this code which make it deserving of
deletion.
1) GHB is a way to
changeset b31580e27d1f in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=b31580e27d1f
description:
cpu: Add ExecFlags debug flag
Adds a debug flag to print out the flags a instruction is tagged with.
diffstat:
src/cpu/SConscript | 3 ++-
changeset a59c189de383 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=a59c189de383
description:
cpu: Remove unused deallocateContext calls
The call paths for de-scheduling a thread are halt() and suspend(), from
the thread context. There is no call
changeset a9023811bf9e in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=a9023811bf9e
description:
alpha,arm,mips,power,x86,cpu,sim: Cleanup activate/deactivate
activate(), suspend(), and halt() used on thread contexts had an
optional
delay parameter.
changeset cba563d00376 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=cba563d00376
description:
cpu: Remove Ozone CPU from the source tree
The Ozone CPU is now very much out of date and completely
non-functional, with no one actively working on
changeset: 10484:6709bbcf564d
user:Michael Adler michael.ad...@intel.com
date:Mon Oct 20 16:44:53 2014 -0500
summary: sim: implement getdents/getdents64 in user mode
Errors:
build/ARM/sim/syscall_emul.cc:881:30: error: use of undeclared identifier
'SYS_getdents'
int
This kind of thing happens fairly often. The compilation is set to error
out if it detects unused variables. Over time the compilers get smarter
and detect variables as unused that for whatever reason the compiler
previously couldn't detect.
From my experience Clang on OS X tends to see most of
changeset e57f5bffc553 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=e57f5bffc553
description:
cpu: Add writeback modeling for drain functionality
It is possible for the O3 CPU to consider itself drained and
later have a squashed instruction perform
changeset 50bbc64efbb8 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=50bbc64efbb8
description:
mem: Delete unused variable in Garnet NetworkLink
With recent changes OSX clang compilation fails due to an unused
variable.
diffstat:
Set the enable_capture parameter from src/dev/arm/RealView.py to false.
On Sat, Nov 22, 2014 at 8:46 PM, Lokesh Jindal via gem5-dev
gem5-dev@gem5.org wrote:
Hello everyone,
While running asimbench, I see that the benchmarks dump file
system.framebuffer.bmp very frequently in the output
changeset b9646f4546ad in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=b9646f4546ad
description:
mem: Rework the structuring of the prefetchers
Re-organizes the prefetcher class structure. Previously the
BasePrefetcher forced multiple assumptions on
changeset 00965520c9f5 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=00965520c9f5
description:
mem: Fix event scheduling issue for prefetches
The cache's MemSidePacketQueue schedules a sendEvent based upon
nextMSHRReadyTime() which is the time when
changeset 0b969a35781f in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=0b969a35781f
description:
mem: Add parameter to reserve MSHR entries for demand access
Adds a new parameter that reserves some number of MSHR entries for
demand
accesses. This
changeset 63edd4a1243f in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=63edd4a1243f
description:
mem: Change prefetcher to use random_mt
Prefechers has used rand() to generate random numers previously.
diffstat:
src/mem/cache/prefetch/stride.cc | 3 ++-
1
changeset 97aa1ee1c2d9 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=97aa1ee1c2d9
description:
mem: Fix bug relating to writebacks and prefetches
Previously the code commented about an unhandled case where it might be
possible for a writeback to
stores could have
the same problem.
Thanks,
Brad
-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Mitch
Hayenga via gem5-dev
Sent: Wednesday, September 03, 2014 4:38 AM
To: gem5-...@m5sim.org
Subject: [gem5-dev] changeset in gem5: cpu: Fix cache
-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Mitch
Hayenga via gem5-dev
Sent: Friday, January 30, 2015 9:34 AM
To: gem5 Developer List
Cc: gem5-...@m5sim.org
Subject: Re: [gem5-dev] changeset in gem5: cpu: Fix cache blocked load
behavior in o3 cpu
Hi Mike,
I'm the one who wrote the initial version of the simpoint
collection/generation a few years ago. I enforced the fastmem option
primarily because I didn't see it necessary to simulate caches during
simpoint generation and it made simulation faster. You can simply disable
this and it
42 matches
Mail list logo
