* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby
passed.
* build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp
passed.
*
There's more to it than that. I started it yesterday and I'll post a diff
today and you can see what I mean.
So one question to you Nate, is what do you prefer, doing a single #if
FULL_SYSTEM in the C++, or doing a if buildEnv[FULL_SYSTEM] in the python so
that the value passed into the C++ is
There's more to it than that. I started it yesterday and I'll post a diff
today and you can see what I mean.
So one question to you Nate, is what do you prefer, doing a single #if
FULL_SYSTEM in the C++, or doing a if buildEnv[FULL_SYSTEM] in the python so
that the value passed into the C++
I think Lisa's pythonic fix is the one where we use the _numCpus
value that's calculated entirely in python (including the +1 offset in
FS mode) and don't attempt the automatic C++ technique that Korey
proposed.
Hey guys,
with the new Ruby memory system coming, how much of the classic memory
I'd definitely like to see us focus our efforts on Ruby. That said,
if you've got the code working, there's no reason not to use it.
Also, I'm guessing that a similar problem will exist in Ruby if the
Ruby cache ever extends its stats to be per context... I expect the
only reason Ruby doesn't
Korey, that's awesome. If you've done it already, then by all means, let's
see it on the review board.
And Steve, you are right, Ruby does not do stats per context, though
recently a set of my pushes made it possible to even pass that information
to Ruby. Nothing in the tree takes advantage of
I am trying to compile m5 and the scons exits with errors.
Following is the compilation command --
scons -j 12 CXX=g++44 CC=gcc44 USE_MYSQL=False RUBY=True
build/ALPHA_SE_MESI_CMP_directory/m5.fast
and errors
In file included from
Nate, I'm trying to test what I've done using se.py (this shouldn't affect
any regression tests because none of those set the formerly-known-as numCpus
value anyway, though, of course i will be a good citizen and still run
them), and somethign about these new python changes prevents me from
Combining FS and SE is a lot like the heterogeneous ISA stuff in that
it's something I'd really like to see happen but also where there are
definitely some steps in the middle. The detail work of combining FS
and SE will be easier, I think, but it will take more conceptual
Hi Korey,
I'm confused. The miss_latency calculated by the sequencer is the miss latency
of the particular request, not just L1 cache hits.
If you're seeing a bunch of minimum latency requests, I suspect something else
is wrong. For instance, is issued_time a cycle value or a tick value?
Nate, since I have provided the option USE_MYSQL=False, why should
mysql.hh even come in to picture?
--
Nilay
On Wed, 20 Apr 2011, nathan binkert wrote:
The solution is to #include base/types.hh in mysql.hh, but to be
honest, I'm not sure how this is even happening. Perhaps you need to
Nate, since I have provided the option USE_MYSQL=False, why should mysql.hh
even come in to picture?
Because that file is being included regardless. I'm actively trying
to squash all of these bugs and I'll be committing some changes soon.
This one is trivial to fix.
Nate
changeset a9d06c894afe in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=a9d06c894afe
description:
fix some build problems from prior changesets
diffstat:
src/arch/arm/interrupts.hh| 1 +
src/arch/arm/linux/system.cc | 1 +
src/arch/arm/table_walker.cc | 3 +++
Because that file is being included regardless. I'm actively trying
to squash all of these bugs and I'll be committing some changes soon.
This one is trivial to fix.
I can't reproduce this bug on my machine, even with USE_MYSQL=False.
Can you try the attached diff? If it works for you, feel
(comments inline)
I'm confused. The miss_latency calculated by the sequencer is the miss
latency of the particular request, not just L1 cache hits.
I think I understand that, but even if it's just L1 hits, let's say that the
L1 latency is 1 and you are running a workload with a high hit rate
It's probably a bit late to bring this up, but won't this remove -all-
directories called build, not just -the- build directory? There's an os
function that checks if two directories are the same. We can use that to
compare the actual build directory with whatever we're recursing down.
That
Yes, you are right and that is intentional.
Some of us discussed this (perhaps off-list), and Brad's earlier
version had another test similar to what you're proposing. However,
you could have multiple build directories under your EXTRAS dir (e.g.,
extras/x86-64/build, extras/x86-32/build, and
Sure, it is recording all miss latencies, including L1 cache hits. And yes,
those L1 hits will show up in the first bucket. However, I don't see how that
is a bug. If you don't want to include L1 hits in the histogram, then look how
the MOESI_hammer protocol tracks separate miss latencies
Hi Brad,
Don't you think this is a misnomer and instead should be called
request_latency: , request_latency_IFETCH, and etc.? I think this is
what is really being measuring anyway: the request latency from when a
request leaves the cpu sequencer and then eventually finishes.
But if you are going
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/649/
---
Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan
20 matches
Mail list logo
