I'm nearly done with the first step of getting parallel M5 working.
-- Add an EventQueue pointer to every SimObject and add
schedule()/deschedule()/reschedule() functions to the Base SimObject
to use that event queue pointer.
-- Change all calls to event scheduling to use that EventQueue
I've created a wiki page with my plan for parallel M5
http://m5sim.org/wiki/index.php/Parallel_M5
Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
I'd actually like to see this changset go back in. It seems that all
that needs to happen is that setPeer should delete the peer if it is a
defaultPort. There are a couple of ways to do this:
1) Have setPeer call disconnect(), though I'm not clear on how the
deletePort() thing is supposed to
I vote for (1) until it can be shown that it matters. A single pointer
doesn't seem like a big deal, especially since most of the things we
create and destroy frequently aren't SimObjects but other classes.
Ali
On Jun 29, 2008, at 12:23 PM, nathan binkert wrote:
I'm nearly done with the
# HG changeset patch
# User Ali Saidi [EMAIL PROTECTED]
# Date 1214782927 14400
# Node ID ada5724fbc53640aa6b85ba82e5a43d2e7a67092
# Parent d9de38fba64c204f5eb5ea87adb9b9c0c9e9c1c6
After a checkpoint (and thus a stats reset), the
not_idle_fraction/notIdleFraction statistic is really wrong.
The
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
# HG changeset patch
# User Ali Saidi [EMAIL PROTECTED]
# Date 1214782929 14400
# Node ID 363df5ea90da6ff8283c0f3d9c29a4e26efbe4a5
# Parent 8f98b8f28e474fc98d16f5e3973b01a5f2b0a6ff
Make the cached virtPort have a thread context so it can do everything that a
newly created one can.
diff --git
# HG changeset patch
# User Ali Saidi [EMAIL PROTECTED]
# Date 1214783163 14400
# Node ID 1c93d818b049e51e3b86c123d3ad86a1555a467b
# Parent 363df5ea90da6ff8283c0f3d9c29a4e26efbe4a5
Change everything to use the cached virtPort rather than created their own each
time.
This appears to work, but I
I vote for (1) until it can be shown that it matters. A single pointer
doesn't seem like a big deal, especially since most of the things we
create and destroy frequently aren't SimObjects but other classes.
Showing that it matters is pretty hard unless you actually do it. A
profile won't
On Sun, Jun 29, 2008 at 4:49 PM, Ali Saidi [EMAIL PROTECTED] wrote:
one question
is how to enforce encourage objects that call getVirtPort() to not cache the
virtual port
since if the CPU changes out from under them it will be worse than useless.
Perhaps a null
function like
there is a status() accessor method, but nothing uses. It seems
unnecessary to to have a method to read the a variable that only the
object that contains that variable uses.
Ali
On Jun 29, 2008, at 7:45 PM, Ali Saidi wrote:
# HG changeset patch
# User Ali Saidi [EMAIL PROTECTED]
# Date
there is a status() accessor method, but nothing uses. It seems
unnecessary to to have a method to read the a variable that only the
object that contains that variable uses.
Why are you no longer serializing the status?
Why is it confusing that both a port and a CPU have a status? There
are
The right thing to do is to either rely on the existing python
framework, or move statements into the normal BaseCPU constructor.
In this instance, I think the former is the correct answer since it's
not exactly clear to me why those three variables must be set to null
in C++. I think the issue
This is probably slightly off topic, but could you explain more
specifically the synchronization event stuff you mention on the wiki
page? It sounds interesting but I can't picture what you're describing.
Gabe
nathan binkert wrote:
I vote for (1) until it can be shown that it matters. A
14 matches
Mail list logo
