changeset 01c540be7e72 in /z/repo/encumbered
details: http://repo.m5sim.org/encumbered?cmd=changeset;node=01c540be7e72
summary: Replace curTick global variable with accessor functions.
diffstat:
eio/eio.cc | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diffs (79 line
iles, you can do:
hg log -vpr dac01f14f20f | filterdiff -i '*.py' -i '*.i' -i '*/core.*' -i
'*/serialize.cc' -i '*/simulate.cc'
Steve
On Fri, Jan 7, 2011 at 10:16 PM, Steve Reinhardt wrote:
> changeset dac01f14f20f in /z/repo/m5
> details: ht
To reply, visit:
> http://reviews.m5sim.org/r/419/
> -------
>
> (Updated 2011-01-10 07:44:05)
>
>
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
>
> Summary
> ---
&g
mann wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/399/
> ---
>
> (Updated 2011-01-10 11:42:35)
>
>
> Review request for Default, Ali Saidi, Gabe Black
---
>
> (Updated 2011-01-10 07:44:05)
>
>
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
>
> Summary
> ---
>
> Time: Add a mechanism to prevent M5 from running faster than re
, Brad Beckmann wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/399/
> ---
>
> (Updated 2011-01-10 15:59:13)
>
>
> Review request for D
request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
>
> Summary
> ---
>
> mem: Added support for Null data packet
>
> The packet now identifies whether static or dynamic data has been allocated
> and
> is used by Ruby to det
On Thu, Jan 13, 2011 at 9:11 AM, Beckmann, Brad wrote:
> By the way, could we add this test to the regression tester?
We really should, and it would be great if we could, but as the caveats
section of the script points out, it relies on se.py/fs.py options that
don't exist in the current regress
p://reviews.m5sim.org/r/343/
> ---
>
> (Updated 2011-01-12 09:08:38)
>
>
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
>
> Summary
> ---
>
> O3: Fix mispredicts from n
--
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/338/
> ---
>
> (Updated 2011-01-12 09:06:31)
>
>
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhar
Yes, it should be a concern... it should work. Did you do a pull on the
encumbered repository? There were some changes there needed to maintain
compatibility with the latest m5 dev repo.
Otherwise you'll need to provide more detail about how things failed.
Steve
On Mon, Jan 17, 2011 at 10:21 A
The one where the EIO code lives. That's it's name, at
http://repo.m5sim.org.
On Mon, Jan 17, 2011 at 12:59 PM, Nilay Vaish wrote:
> What do you mean by the encumbered repository?
>
>
> On Mon, 17 Jan 2011, Steve Reinhardt wrote:
>
> Yes, it should be a concern...
t for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
>
> Summary
> ---
>
> O3: Fixes the way prefetches are handled inside the iew unit. This patch
> prevents the prefetch being added to the instCommit queue twice.
>
>
> Diffs
>
---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/419/
> ---
>
> (Updated 2011-01-18 16:49:14)
>
>
> Review request for Default, Ali Saidi, Gabe Black, Ste
eview request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
>
> Summary
> ---
>
> Time: Add a mechanism to prevent M5 from running faster than real time.
>
> M5 skips over any simulated time where it doesn't have any work to
011-01-18 14:34:11)
>
>
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
>
> Summary
> ---
>
> SimpleCPU: Fix a case where a DTLB fault redirects fetch and an I-side walk
> occurs.
>
> This change fixes an
What's the deal with Histogram::add()? Either it's too slow or it's being
called too much, I'd say, unless we're tracking some incredibly vital
statistics there. Can you use the call graph part of the profile to find
where most of the calls are coming from?
Also, can you look at the stats and ve
0.000185 # Percentage of
> non-idle cycles
> system.cpu5.numCycles 399900914 # number of cpu
> cycles simulated
> system.cpu5.num_insts8413 # Number of
> instructions executed
> system.cpu5.num_refs 2862 # Number o
changeset 494b5426e70d in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=494b5426e70d
description:
checkpointing: fix bug from curTick accessor conversion.
Regex replacement of curTick with curTick() accidentally
changed checkpoint key string for serializat
Hi Rick,
Thanks for figuring this out. The last one is clearly just my dumb mistake;
I just committed a fix. The serialization/unserialization of mode is an
obvious enough oversight too.
I'm not quite so sure about the dup fix though... I think the original
sim_fd_obj() is doing the right thing
>> directly, but it would at least make things look more consistent to
>> always (or almost always) use SERIALIZE_FOO.
>>
>> Gabe
>>
>> On 01/20/11 22:11, Steve Reinhardt wrote:
>> > changeset 494b5426e70d in /z/repo/m5
>> > details: http:/
> I agree with your point about dup. I imagine we can keep an additional
> field that determines whether a file descriptor was created by dup and if
> so, re-open it with dup at the point of checkpoint restore. I will work on a
> fix and post the diff.
>
> Best,
> -Rick
Not saying you have to do it this way; a smaller change that universally
improves on the status quo and makes it work for your situation is fine with
me...
On Fri, Jan 21, 2011 at 11:21 AM, Steve Reinhardt wrote:
> I was thinking about this a little more, and I think if we really want to
&g
On Fri, Jan 21, 2011 at 11:33 AM, nathan binkert wrote:
> We had discussed changing serialization so that there was a serializer
> class and paramOut/paramIn were methods of that class (getting rid of
> the os parameter for ParamOut and the cp and section parameters of
> param in). [...]
>
Agre
In general, the algorithm should probably be:
- pick one and try it... if it works for you, great.
- if not, try the other one
- if neither one works, ask on m5-users
If people followed this approach, then it wouldn't matter nearly as much
which one they started with.
Steve
On Fri, Jan 21, 2011
On Sun, Jan 23, 2011 at 4:08 PM, Nilay Vaish wrote:
> On Sun, 23 Jan 2011, Korey Sewell wrote:
>
> In sendFetch(), it calls sendTiming() which would then call the recvTiming
>> on the cache port since those two should be binded as peers.
>>
>> I'm a little unsure of how the RubyPort, Sequencer,
Apparently not...
When you say "it didn't work", what do you mean? Maybe if you ask some more
specific questions it will be easier for us to provide some clues.
Steve
On Tue, Jan 25, 2011 at 5:36 AM, Eberle wrote:
> Any ideas?
>
> On Fri, Jan 21, 2011 at 5:00 PM, Eberle wrote:
>
>> Hi,
>>
>>
This is pretty interesting. I hadn't thought that it would matter, but if
an unparented object is listed as a parameter to more than one other object
then the one that it gets parented too will depend on the order you call
adoptOrphanParams(). You're absolutely right that you don't want to depend
o parents. If it so happens that when you
> call root.descendents() that you get switch_cpus first, then you will add
> workload as a child of switch_cpus.
>
>
>>
>> On Tue, Jan 25, 2011 at 12:31 PM, Steve Reinhardt wrote:
>>
>>> This is pretty interesting. I
On Thu, Jan 27, 2011 at 4:36 AM, Nilay Vaish wrote:
> I tried caching the index for the MRU block, so that the hash table need
> not be looked up. It is hard to point if there is a speed up or not. When
> I run m5.prof, profile results show that time taken by
> CacheMemory::lookup() drops from ~
On Thu, Jan 27, 2011 at 5:24 AM, Nilay Vaish wrote:
>
>> I tested my hypothesis yesterday. About 90% of the messages have
> destination count = 1. I think, for such messages, we should avoid going
> through the entire routing table. Instead, we should also keep a mapping
> from destination to set
On Thu, Jan 27, 2011 at 4:01 PM, Nilay Vaish wrote:
>
>>
>> I also have an implementation that performs linear search of cache sets
> instead of hash table lookup. Again, I saw small improvement. But as you
> mentioned, when the associativity will go up, linear search will perform
> worse. Profil
---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/432/
> ---
>
> (Updated 2011-01-18 14:49:34)
>
>
> Review request for Default, Ali
t for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
>
> Summary
> ---
>
> O3: Fix pipeline restart when a table walk completes in the fetch stage.
>
> When a table walk is initiated by the fetch stage, the CPU can
> potentially move to
--
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/422/
> ---
>
> (Updated 2011-01-12 09:12:18)
>
>
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, an
On Sun, Jan 30, 2011 at 6:31 PM, Gabe Black wrote:
> Are you ok with this original change and renaming files later?
I'm fine with that.
> What do
> you think of the new name?
>
It looks to me like fault.hh is basically just forward declarations while
faults.hh has the actual definitions, ri
-
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/455/
> ---
>
> (Updated 2011-01-29 15:12:55)
>
>
> Review request for Default, Ali Said
gt; (Updated 2011-01-29 15:14:02)
>
>
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
>
> Summary
> ---
>
> X86: Add scripts to support X86 FS configurations in the regressions.
>
>
> Diffs
> ---
On Mon, Jan 31, 2011 at 9:32 AM, nathan binkert wrote:
> >> Are you ok with this original change and renaming files later?
> > I'm fine with that.
> Me too.
>
> > It looks to me like fault.hh is basically just forward declarations while
> > faults.hh has the actual definitions, right? Do we hav
On Mon, Jan 31, 2011 at 12:28 PM, Gabe Black wrote:
>This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/455/
>
> On January 31st, 2011, 7:14 a.m., *Steve Reinhardt* wrote:
>
> I don't see why this is necessary.
> 1. I don'
s is for the APICs to talk to
>> each other. And yes, a comment would be a good idea. I didn't want to
>> put on all the trimmings if this was a dead end.
>>
>> Gabe
>>
>> Steve Reinhardt wrote:
>>
>>> My initial reaction is "even if this w
t;> treated specially, and one of the others is for the APICs to talk to
>> each other. And yes, a comment would be a good idea. I didn't want to
>> put on all the trimmings if this was a dead end.
>>
>> Gabe
>>
>> Steve Reinhardt wrote:
>>
>>&g
If we can't do a scanner, I don't have a huge problem with listing output
files explicitly... yea, it's not as elegant, but I don't expect it to
change a lot either.
Steve
On Feb 2, 2011 2:25 PM, "Gabe Black" wrote:
> On 02/02/11 13:05, nathan binkert wrote:
>>> So, one important question apart f
Yea, you'd think so... I guess my point is really that we should design the
best mechanism wrt the language first, then worry about scons second, and
even if the best mechanism requires us to explicitly list dependencies in
scons that's probably not sufficient reason to reject it. And I think
Nate
ill a long, long time for a regression. I notice that the number of ticks
>> for the benchmarks that are in common with Alpha is about 4 times higher,
>> suggesting a performance bug of some sort (I doubt x86 gcc is 4X worse).
>>
>> Gabe
>>
>> On 02/01/11 17:23,
>
> !entry->writable && (inUser || cr0.wp) is used here and in the if below. This
> would be easier to read if that was in a temporary variable, maybe called
> badWrite. Nate would probably yell at me that it should be bad_write because
> it's local. He'd be right, but that would be inconsistent
On Sat, Feb 5, 2011 at 12:35 PM, Gabe Black wrote:
> On 02/05/11 10:05, Steve Reinhardt wrote:
>
>!entry->writable && (inUser || cr0.wp) is used here and in the if below.
> This would be easier to read if that was in a temporary variable, maybe
> called badWrite
On Sat, Feb 5, 2011 at 12:22 PM, Gabe Black wrote:
> My point is that you -don't- have it without the reference outputs. The
> reference outputs are how you make it exist in this case.
>
> Gabe
>
>
> On 02/05/11 10:00, Steve Reinhardt wrote:
>
> So what's the
On Mon, Feb 7, 2011 at 9:15 AM, Beckmann, Brad wrote:
> However, one thing that will help me in the future is making sure that all
> of us have the capability to run all regress tests. Many of us, including
> myself, don't have log in access to zizzer at Michigan, and thus it is very
> hard for m
il. To reply, visit:
> http://reviews.m5sim.org/r/473/
> ---
>
> (Updated 2011-02-11 16:43:37)
>
>
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
>
>
; http://reviews.m5sim.org/r/471/
> ---
>
> (Updated 2011-02-11 08:21:47)
>
>
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
>
> Summary
> ---
>
> X86: Define fault objects t
>
> 1. I like the idea of moving this out of x86, although practically speaking I
> don't know that any other ISA would be able to use it right now. I'll still
> move it though. This is, of course, talking about the faults themselves and
> not the instruction objects. The instructions are x86 sp
On Fri, Feb 11, 2011 at 12:45 PM, Gabe Black wrote:
> This is for error checking in microcode. Lets say you have microcode like
> this:
>
> // Check for flag foo to enable feature bar
> and t1, t2, t3
> // If foo isn't set, skip over the microcode for bar
> br afterBar
> panic "Feature bar not im
in the backing
> function. It would probably be reasonable to axe the fatal version of the
> fault and microop and leave the other three. Do you think that's worthwhile,
> though, since it's the only one and that would be a little asymmetric? I'm
> ok with it either way so
Hi Gabe,
I just got around to reading this... please fill me in with more design
details as you work on this, as I'd like to keep on top of what you're doing
and (perhaps) be in a position to offer some suggestions.
Thanks,
Steve
On Fri, Feb 11, 2011 at 4:16 PM, Gabriel Michael Black <
gbl...@e
, visit:
> http://reviews.m5sim.org/r/485/
> ---
>
> (Updated 2011-02-13 19:13:33)
>
>
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
>
> Summary
> ---
>
Yea, the protocol does assume that a full cache-block request is from
another coherent entity. Has O3 always fetched full cache blocks at a
time? If so, then I'm also surprised we haven't seen it (or maybe we have
seen it, but not recognized it).
Getting rid of this code would solve the problem,
On Sun, Feb 20, 2011 at 8:34 PM, Ali Saidi wrote:
> The fetch stage seems to have done that forever. I think because we're
> using RAM as a filesystem for ARM at the moment that is one reason why it's
> more prone to pop-up in this case, but it seems like it's been an issue for
> a long time.
>
>
On Tue, Feb 22, 2011 at 9:31 AM, nathan binkert wrote:
> > Oh, actually, this made me think of something I wanted to bring up. What
> > we're talking about now is basically a config file, but we already have
> > something called that. I was describing M5 to some folks at work a little
> > while a
I'm coming into this thread kind of late... I just started using the new
Gmail "Priority Inbox" and it told me that this wasn't an important thread,
so I believed it.
Based on what I've read so far though, I don't see where simply documenting
and providing some examples of how to use Nate's .m5 fe
On Wed, Feb 23, 2011 at 5:03 PM, Gabe Black wrote:
> Forgive my ignorance here, but why is the limit event set up each time
> simulate is called? Couldn't it just be a member of the event queue
> class and always stuck at the end and left there?
>
The limit can change from call to call, and it's
On Thu, Feb 24, 2011 at 11:08 AM, Beckmann, Brad wrote:
> So we probably don't want to pass speculative store data to the RubyPort,
> but what about speculative load and store requests? I suspect we do want to
> send them to the RubyPort before the speculation is confirmed. That might
> require
On Thu, Feb 24, 2011 at 1:32 PM, Nilay Vaish wrote:
> On Thu, 24 Feb 2011, Beckmann, Brad wrote:
>
> Steve, I think we are in agreement here and we may just be disagreeing
>> with the definition of speculative. From the Ruby perspective, I don't
>> think it really matters...I don't think there
k. The coalescing
> functionality can probably be eliminated, but I think the other functionality
> needs to remain.
>
> Brad
>
>
> From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org
>
> ] On Behalf Of Steve Reinhardt
> Sent: Thursday, February 24, 20
- Steve
On 2011-02-25 21:04:34, Ali Saidi wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/509/
> ---
>
> (Updated 2011-02-25 21:
lly generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/514/
> ---
>
> (Updated 2011-02-26 01:44:53)
>
>
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
Yea, double inheritance from SimObjects seems like an obviously bad idea to
me.
I think part of the problem is that we don't always expose the entire C++
hierarchy to swig just for simplicity, and if some of those "hidden" classes
have multiple base classes then swig could get confused. If this r
The m5 memtester supports functional accesses (there's a percent_functional
parameter on the MemTest object). I don't know if anyone's run the
memtester with Ruby though. Seems like it should work.
Steve
On Tue, Mar 1, 2011 at 8:39 AM, Joel Hestness wrote:
> Hi Nilay,
> I don't know if there
eviews.m5sim.org/r/522/
> ---
>
> (Updated 2011-02-28 04:54:41)
>
>
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
>
> Summary
> ---
>
> SCon
eview request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
>
> Summary
> ---
>
> O3: Cleanup the commitInfo comm struct.
>
> Get rid of unused members and use base types rather than derrived values
> where possible to limit amo
> On 2011-03-02 09:21:38, Steve Reinhardt wrote:
> > I'm willing to be convinced on this one, but I'd argue that the
> > inconsistency is that VERBOSE should be lowercase, not that update_ref
> > should be uppercase... I think I originally made update_ref lowerc
t for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
>
> Summary
> ---
>
> SCons: Clean up some inconsistent capitalization in scons options.
>
>
> Diffs
> -
>
> SConstruct cf1afc88070f
> src/mem/protoco
The issue here is that we have a significant number of existing checkpoints
for large systems that would be prohibitively expensive to regenerate. If
it would work to just have the unserialize code default the value to 0 if
it's missing, that would be great. It sounds like you are saying that, bu
On Fri, Mar 4, 2011 at 4:34 PM, Gabe Black wrote:
>
> > In general, we need to be much more cautious about updates that break
> > existing checkpoints.
>
> [...] Caution was not a factor.
>
Yea, that's my point ;-).
> As I said last time this came up, I'll won't take breaking checkpoints
> lig
Right now it may only be documented in the ASPLOS tutorial slides.
Basically you don't generally access c++ data from python, you just set up
parameters in python that are accessible from C++. If you want to do
something fancier you have to do your own SWIG wrapping, which I'm guessing
is not what
Sorry I missed this thread... I just read Nilay's response about python
issues and he pointed me over here.
One thing we should think about is that we really only want the caches
within a single system to be flushed at once... I know that it's unlikely
that anyone will want to model two systems wi
Forgot to mention that this is how we handle registering all the thread
contexts within a system... you can look at that code (in the CPU models and
in System) for an example.
On Tue, Mar 8, 2011 at 7:16 AM, Steve Reinhardt wrote:
> Sorry I missed this thread... I just read Nilay's
erarchy." \
> RuntimeError: system.l1_cntrl0.L1DcacheMemory: Cycle found in configuration
> hierarchy.
>
>
> --
> Nilay
>
>
> On Tue, 8 Mar 2011, Steve Reinhardt wrote:
>
> Forgot to mention that this is how we handle registering all the thread
>> contexts wit
Int("");
>replacement_policy = Param.String("PSEUDO_LRU", "");
>start_index_bit = Param.Int(6, "index start, default 6 for 64-byte
> line");
>
> --
> Nilay
>
> On Tue, March 8, 2011 6:35 pm, Steve Reinhardt wrote:
s on the function call Param.RubySystem(Parent.any,
> "Ruby System") ?
>
> Nilay
>
>
> On Wed, 9 Mar 2011, Steve Reinhardt wrote:
>
> Does the RubySystem object have a pointer to a RubyCache object?
>>
>> You could also go into the python code and add som
I'm fine with getting rid of it. For me it's been the source of problems,
particularly with update_ref, and I haven't personally seen a benefit.
Steve
On Wed, Mar 9, 2011 at 2:19 PM, Gabe Black wrote:
> A while back I proposed we add the mercurial changeset to the binary so
> that it could pri
ld not the cache controllers be part of ruby, instead of being part of
> system? Once they become part of ruby, it should be possible to traverse the
> controller array and figure out all the caches.
>
>
> Nilay
>
> On Wed, 9 Mar 2011, Steve Reinhardt wrote:
>
> I think you
On Wed, Mar 9, 2011 at 5:30 PM, Beckmann, Brad wrote:
> I believe the L1DcacheMemory is created right after system because inside
> each protocol file the first thing attached to the system is the l1
> controllers. That way the controllers get a more descriptive name than what
> they are as relat
root
> Creating system params
> Creating system
> Done creating system
> Creating system.l1_cntrl0 params
>
>
> Nilay
>
> On Wed, 9 Mar 2011, Steve Reinhardt wrote:
>
> It seems odd that it tries to create L1DcacheMemory right after it creates
>> system
Thanks! I hope this helps.
Steve
On Wed, Mar 9, 2011 at 10:56 PM, Ali Saidi wrote:
> Everyone,
>
> I've just added math captcha to the wiki to prevent spam. Please let me
> know if you run into any issues.
>
> Thanks,
> Ali
>
> ___
> m5-dev mailing l
Brad pointed out that he habitually sets NO_FAST_ALLOC when compiling
m5.debug because the way FastAlloc handles memory allocation tends to be
tolerant of memory allocation errors (like reusing objects after they've
been deleted), and he's run across other people's bugs simply by running
with NO_FA
hu, Mar 10, 2011 at 11:03 AM, Gabe Black wrote:
>This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/555/
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
> By Gabe Black.
> Description
>
>
ngeset from last year.
>
> By the way, this reminds me that the directed test code is another piece
> that should be added to the regression tester. I'll add that to my list.
>
> Brad
>
>
> > -Original Message-----
> > From: m5-dev-boun...@m5sim.org [mailto
lly
> is faster than the built in allocator? It's pretty darned old and
> memory allocators are pretty modern now.
>
> Nate
>
> On Thu, Mar 10, 2011 at 8:23 AM, Steve Reinhardt wrote:
> > Brad pointed out that he habitually sets NO_FAST_ALLOC when compiling
> >
I'm not sure this is a great solution, since eventually it would be nice to
get rid of RubySystem as a separate object and just use System. (There's
really no non-historical reason to have both.)
I still don't quite understand where the cycles are coming from; the outputs
you sent after adding th
eter to another SimObject.
Steve
On Thu, Mar 10, 2011 at 10:24 PM, Steve Reinhardt wrote:
> I'm not sure this is a great solution, since eventually it would be nice to
> get rid of RubySystem as a separate object and just use System. (There's
> really no non-historical reason to h
On Fri, Mar 11, 2011 at 6:57 AM, Nilay Vaish wrote:
> On Thu, 10 Mar 2011, Nilay Vaish wrote:
>
> Creating root params
>> Creating root
>> Getting root
>> Done creating root
>> Creating system params
>> Getting system.physmem
>> Creating system
>> Getting system
>> Done creating system
>
s.m5sim.org/r/564/
> ---
>
> (Updated 2011-03-11 12:06:28)
>
>
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
>
> Summary
> ---
>
> sim: Fixes Simulation.py to allow more than 1 core for
On Fri, Mar 11, 2011 at 2:27 PM, Beckmann, Brad wrote:
>
> > Finally, it occurs to me that we avoid these issues to some extent in the
> > classic m5 memory hierarchy by using ports rather than parameters to set
> up
> > inter-object connections; maybe we should consider extending or adapting
> >
Hi Gabe,
Were you expecting these to be run automatically? Turns out they['re not, I
think because X86_FS is not listed as a valid build in util/regress.
Also, I'm not sure what our definition of "quick" is, but it might be worth
moving the atomic boot test to the "quick" category to make sure i
t for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
>
> Summary
> ---
>
> Regressions: Make X86_FS run automatically.
>
>
> Diffs
> -
>
> util/regress 5138d1e453f1
>
> Diff: http://revie
On Sat, Mar 12, 2011 at 1:34 PM, Nilay Vaish wrote:
> On Fri, 11 Mar 2011, Steve Reinhardt wrote:
>
>>
>>
>> Thanks for the explanation... I was expecting to see a loop on
>> L1DcacheMemory like before and I missed the one on system.ruby.network.
>>
>>
On Sat, Mar 12, 2011 at 5:45 PM, Nilay Vaish wrote:
> On Sat, 12 Mar 2011, Steve Reinhardt wrote:
>
> Can't we loop through the directory controllers in python to calculate the
>> total size, then pass that size as a parameter to RubySystem? There's no
>> reason f
Just ran across this... maybe something similar would work for us in terms
of handling binaries for regressions.
http://wiki.netbeans.org/ExternalBinaries
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/586/
---
Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan
901 - 1000 of 1287 matches
Mail list logo
