I believe all the FAILEDs below are just the long runs whose stats didn't
get updated after my cache changes. I can't tell what happened on the last
one (the Error 3), so I'm hypothesizing that it was just a pool glitch and
I'm rerunning now.
Steve
On Sun, Mar 16, 2008 at 8:10 AM, Cron Daemon
aborted at cycle 10209991750
Aborted (core dumped)
Ali
On Mar 15, 2008, at 9:19 PM, Ali Saidi wrote:
Fixed...
Attached is a memtest diff that makes the problem show up in 1 hour
rather than 6.
Ali
memtest1.diff
On Mar 15, 2008, at 7:23 PM, Steve Reinhardt wrote:
Does
looks like it...
On Sun, Mar 16, 2008 at 11:37 AM, nathan binkert [EMAIL PROTECTED] wrote:
Generally, yes. Memory leak?
2008/3/16 Steve Reinhardt [EMAIL PROTECTED]:
Funny, I got this error:
system.cpu7: completed 630 read accesses @9833512177
system.cpu5: completed 630 read
On Mon, Apr 7, 2008 at 9:08 AM, Ali Saidi [EMAIL PROTECTED] wrote:
Well, yes, but we'll have to duplicate this code in the libelf SConscript:
# Do this after we save setting back, or else we'll tack on an
# extra 'qdo' every time we run scons.
if env['BATCH']:
env['CC'] =
Is it too difficult to track down which piece of BIOS info you copied
contains the DRAM size, or copy the info from a machine with less RAM?
In the long run we'll want to make it configurable, and clearly in
the real world it's OK to have a PC with 4GB of RAM...
On Sat, Apr 26, 2008 at 3:46 PM,
Yea, sounds like a bug to me.
Steve
On Sat, May 3, 2008 at 8:55 AM, nathan binkert [EMAIL PROTECTED] wrote:
I'm guessing the answer is no.
Nate
On Sat, May 3, 2008 at 8:34 AM, Gabe Black [EMAIL PROTECTED] wrote:
That turns on the output in the trace printing code, but it can't print
Do umich.edu addresses really last forever? I know I only got 'stever'
after they found that the previous owner had left. Maybe that policy
applies to students but not faculty... though I pity the fool who gets stuck
with my email address if they take it away from me.
On Mon, May 19, 2008 at
small number of non-alumni, it's not worth
trying to keep the two groups separate.
Anyway, which address do you want? gmail?
Nate
2008/5/20 Steve Reinhardt [EMAIL PROTECTED]:
Do umich.edu addresses really last forever? I know I only got 'stever'
after they found that the previous owner
, especially where there were just usernames with
no e-mail address from the BK days. People can pick whatever they
want.
Nate
2008/5/20 Steve Reinhardt [EMAIL PROTECTED]:
I just emailed ITD to see what their policy is. Lots of choices... I'm
guessing the only way that DCO would stop
On Wed, May 21, 2008 at 5:44 PM, Gabe Black [EMAIL PROTECTED] wrote:
The kernel is now getting to a point where it's trying to calibrate the
timer in the local APIC against the TSC register. In order to mimic that,
I'm going to need to create an event to fire when the timer is supposed to
Thanks for the email... can't say I really follow all the nuances
after a quick read, but I'm glad you're thinking about it. Just a few
comments off the top of my head:
The common indexing scheme across all register types is something we
inherited from SimpleScalar. It's not ideal for actually
My biggest worry about 3-6 months is that we often have fixes that are
important and more recent than 3-6 months. Beta 5 is barely three
months old and has at least two important patches, right?
I was just going to use that same evidence to argue the opposite...
the fact that beta5 is 3
Sort of a multi-reply here...
On Sat, Jun 7, 2008 at 11:36 AM, Ali Saidi [EMAIL PROTECTED] wrote:
To jump in here, the thing is we're not finding these bugs. Saying
there needs to be 3 months of testing before we release something
marked stable only works if its likely that the people running
On Thu, Jun 12, 2008 at 11:26 AM, Gabe Black [EMAIL PROTECTED] wrote:
How about instead of Params.some_class the syntax would be
Params(some_class) where Params is more like a class than a module? Then
you could look up the information for the class you're dealing with
without ever having to
On Thu, Jun 12, 2008 at 5:44 PM, nathan binkert [EMAIL PROTECTED] wrote:
How about instead of Params.some_class the syntax would be
Params(some_class) where Params is more like a class than a module? Then
you could look up the information for the class you're dealing with
without ever having
On Thu, Jun 12, 2008 at 5:51 PM, nathan binkert [EMAIL PROTECTED] wrote:
I was wondering why we had both 'type' and 'cxx_classname'... last
time I recall working on that code (before Nate finished the params
auto-gen stuff), the point of 'type' was to be the C++ class name.
When is the
changeset 9ffc2be2d925 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9ffc2be2d925
summary: Get rid of bogus cache assertion.
changeset b84a60dbf862 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=b84a60dbf862
summary: Get rid of bogus bus assertion.
On Fri, Jun 13, 2008 at 3:33 PM, nathan binkert [EMAIL PROTECTED] wrote:
Today, it is our pleasure to announce the public availability of the
M5 repository.
Great job everybody. Hopefully Friday the 13th doesn't turn out to be
a problem :)
Thanks to everyone for all the effort.
BTW, the
I sympathize with Ali's concerns... the current situation is pretty
much the opposite extreme of the 3-6 month release cycle I was
advocating not that long ago. My main motivation was that a longer
cycle would allow more time for people to find problems, and the
criticism was that a lot of the
On Sun, Jun 15, 2008 at 9:37 PM, Nathan Binkert [EMAIL PROTECTED] wrote:
changeset 758c2413765a in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=758c2413765a
summary: port: Clean up default port setup and port switchover code.
[...]
diff -r 7c18f61da616 -r 758c2413765a
I was strictly talking about the port.cc changes... my diff doesn't
touch base.cc, and I don't think it does much in port.hh either. So
in that context, your answer seems to be no...
Steve
On Mon, Jun 16, 2008 at 11:33 AM, nathan binkert [EMAIL PROTECTED] wrote:
Is there anything in your
I'm trying to clean up the DefaultPort code so that when you leave a
port unconnected and then try to use it you get a message that tells
you which port was unconnected. This basically involves dynamically
allocating a DefaultPort every time you create a normal port to serve
as its peer until it
changeset 94a7bb476fca in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=94a7bb476fca
summary: Generate more useful error messages for unconnected ports.
changeset 88f1e9295945 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=88f1e9295945
summary: Make bus
See Brad's email to m5-users.
On Tue, Jun 24, 2008 at 5:40 PM, nathan binkert [EMAIL PROTECTED] wrote:
What exactly broke? I was using checkpointing successfully with that change.
Also, In the future, please use the full changeset id since the
numbers change all the time.
Nate
On Tue,
I think the easiest short-term fix is just to revert that changeset...
the only thing it provides is better error messages, so there's no big
loss for that. We can resurrect it once we fix the memory leak.
Steve
On Fri, Jun 27, 2008 at 5:32 PM, nathan binkert [EMAIL PROTECTED] wrote:
I thought
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
On Mon, Jun 30, 2008 at 8:26 AM, Ali Saidi [EMAIL PROTECTED] wrote:
On the other hand, if during the switchover the new CPU starts
connecting to the same ports that the old one did, won't my once and
future patch mean that the old CPU's port gets dicsonnected and
hooked
up to a defaultPort,
Nate and I had some discussions the other week along with Brad
Beckmann about improving M5's ability to support other coherence
protocols. I put together an initial design document on the wiki
here:
http://m5sim.org/wiki/index.php/Modular_Coherence_Protocols
Note that even though I tried to
getting ready to go to California but then I'll spend a
really long time in a car where I could read this over at length.
Gabe
Steve Reinhardt wrote:
Nate and I had some discussions the other week along with Brad
Beckmann about improving M5's ability to support other coherence
protocols. I
Is this a bug in the current repo head? If so, please be more
specific so we can commit the patch...
Thanks,
Steve
On Fri, Jul 4, 2008 at 3:23 PM, Rick Strong [EMAIL PROTECTED] wrote:
Your second paragraph seems to be spot on. The problem was a redundant
delete of pkt-req in
should find those other N:1 cases and fix them too.)
Steve
On Tue, Jul 8, 2008 at 6:52 AM, Steve Reinhardt [EMAIL PROTECTED] wrote:
I think someone just needs to reapply it and test it.
Steve
On Mon, Jul 7, 2008 at 9:11 PM, nathan binkert [EMAIL PROTECTED] wrote:
So, you committed that fix
Thanks, I'm happier now. It's a little funny that in the first diff
you split out the Debug structure and in the second diff you fold it
back in again... as I was reading the first diff I thought didn't we
decide not to do that?. Not a big deal, just seems redundant.
Committing the FIFO code
On a separate but related note, does anybody care if we change the
notify template to include the full commit description and not just
the first-line summary? As far as I can tell, the single-changeset
template does this already, but since we're using the changegroup
hook, it just uses the first
Nate,
Did you ever get Michael's libm5 diff into the tree? I don't see any
evidence of it. We actually have a need for it so it would be great
to have the code ASAP... if there are issues with committing it, could
you just send it to us?
Actually I don't see evidence of Michael's other patches
No, please base your patches on m5 (the development repo) rather than
m5-stable, as that's where we'll want to integrate them.
Thanks,
Steve
2008/7/12 jiayuan meng [EMAIL PROTECTED]:
I'm going to pull the repository of m5_stable and base my patches upon this
version, will that be fine?
I'm working on adding a new flavor of assertion inspired by what I've
seen in some unit-testing frameworks. The idea is that if you assert
foo == 3 and it fails, it would be nice to know what the actual
value of foo was without having to rerun the simulation or load up the
core dump (if you even
On Mon, Jul 14, 2008 at 2:30 PM, Gabriel Michael Black
[EMAIL PROTECTED] wrote:
Sorry to butt into the conversation, but I've thought before that it
would be really handy to have asserts that printed out a message rather
than just the condition that triggered them. It would be handy to be
able
I'm running into trouble with multilevel caches, default responders,
and misspeculated accesses, and the way I'd like to fix it is to
overhaul things a bit... so I'd like to solicit some input on whether
it'll work before I go at it.
The setup is a little complicated, but the basic issues are:
I plan to leave the existing explicit default responders alone, yes.
I will probably need to add an explicit default responder on the main
memory bus to deal with misspeculated cacheable accesses to replace
all the implicit default responders I'll be getting rid of.
On busses where the caches are
changeset c1f203a35cc3 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=c1f203a35cc3
description:
Add missing newlines to Bus DPRINTFs.
diffstat:
1 file changed, 1 insertion(+), 1 deletion(-)
src/mem/bus.cc |2 +-
diffs (16 lines):
diff -r 90d6811d5ea6 -r
changeset 52bcc301b467 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=52bcc301b467
description:
Use ReadResp instead of LoadLockedResp for LoadLockedReq responses.
diffstat:
2 files changed, 3 insertions(+), 2 deletions(-)
src/cpu/simple/timing.cc |2 +-
changeset 992aeed13743 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=992aeed13743
description:
Get rid of useless m5_assert macro.
Its only purpose was to print the cycle number but that already
happens in the SIGABRT handler. No one used it anyway.
Funny, I just noticed this the other day myself. The default behavior
should definitely be to print at commit (as we do now) because we want to be
able to generate a program-order list of committed instructions to see what
the CPU is doing functionally, and to compare with simpler models to
Hi Yungang,
Thanks for the patch. Have you corresponded with any of the DRAMSim
developers about this? Prof. Bruce Jacob told me a while ago that they had
already integrated DRAMSim into M5, but hadn't gotten around to sending us
the code. I don't know if their integration has any more
So we just got mildly bit by the '1t' default latency on PhysicalMemory, so
I'm ready to change it to something a little more realistic (say 30ns).
This will involve rerunning all the regressions to generate new stats. If
anyone is thinking of committing anything that will require a full stats
On Fri, Aug 1, 2008 at 5:52 PM, nathan binkert [EMAIL PROTECTED] wrote:
I sent out e-mail a while ago about changing some default output file
names.
Yea, the other discussion we've been having about output redirection
reminded me of this, and made me wonder what had happened here... I guess
changeset cf280b3621cf in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=cf280b3621cf
description:
Make default PhysicalMemory latency slightly more realistic.
Also update stats to reflect change.
diffstat:
96 files changed, 356 insertions(+), 611 deletions(-)
That seems pretty cool to me. I remember when we decided to integrate
python we had the extending vs embedding debate, and now it looks like we
can have it both ways.
Steve
On Sun, Aug 3, 2008 at 8:50 PM, nathan binkert [EMAIL PROTECTED] wrote:
So, the patch I committed earlier today allows
changeset e5fbd38bc828 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=e5fbd38bc828
description:
Add -r/-e options to redirect stdout/stderr.
Better than using shell since it automatically uses -d directory
for output files (creating it as needed).
changeset 2764c7769ee3 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=2764c7769ee3
description:
Minor fix for test/SConscript... forgot to 'qref' before 'qdel', argh.
diffstat:
0 files changed
diffs (12 lines):
diff -r abb8846b2e62 -r 2764c7769ee3 tests/SConscript
changeset cdcfaac59d70 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=cdcfaac59d70
description:
Get rid of outputStream... wasn't really being used
(except for warn()) and new -r/-e options make it
not worth fixing.
diffstat:
2 files changed, 6
changeset 10a17e8a6d35 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=10a17e8a6d35
description:
Make time format in 'started' line same as 'compiled'.
Also make -B output consistent with normal header, and
only include actual build options.
diffstat:
1
On the topic of style violations, I've seen an increasing number of 'if('
and 'for(' (with no space) creeping in (see below). Another thing I've seen
that irritates me (but isn't officially banned by the style code ... yet
...) is C++-style comments with no space between the // and the comment:
Right now the bus supports broadcast, but only for snooping. Also for
future interconnects there isn't necessarily a plan to maintain broadcast
capability (though of course if it's really needed then we would have to).
Is there any particular reason (other than efficiency) why having the
at the state of
the others.
Gabe
Steve Reinhardt wrote:
Right now the bus supports broadcast, but only for snooping. Also for
future interconnects there isn't necessarily a plan to maintain
broadcast capability (though of course if it's really needed then we
would have
As far as I can tell, this is an NFS sync issue on the pool with the strip
command... the link and the strip are run on separate pool nodes, and strip
fails to find the unstripped binary and dies. Did someone get aggressive
about farming things out? I thought we originally only did compiles and
, and that you can
have an arbitrary number of special registers that behave in arbitrary
ways.
Gabe
Steve Reinhardt wrote:
At least for Alpha ALU ops, all the ones with a dest reg of r31 should
get decoded to nop. The original code for zeroing out the zero
register was inherited from
could write to the zero register to special case them
all.
In a lot of cases in x86 at least you can't blindly replace the instruction
with a nop because, for instance, the control flags need to be updated.
Gabe
Quoting Steve Reinhardt [EMAIL PROTECTED]:
What about dependencies? One thing
to implement things that seems obviously
best.
Gabe
Quoting Steve Reinhardt [EMAIL PROTECTED]:
The memory system doesn't do any segmentation. It will choke if you try
and
do a single access that spans cache blocks in cached memory. For
uncached
physical accesses, I don't know
Any cacheable request will get snooped by any device that says it wants
snoops (e.g., a cache or the cpu). Are you sure the request that's getting
snooped is marked uncacheable?
Steve
On Sun, Sep 7, 2008 at 2:20 PM, Gabe Black [EMAIL PROTECTED] wrote:
I'm still working on these interrupt
On Wed, Sep 17, 2008 at 12:14 AM, Gabe Black [EMAIL PROTECTED] wrote:
I think we're talking about mostly the same thing. The ROM bit would be
global, but in the same sense that the PC is global.
OK, I'll buy that... it's global in that there's one per thread context, but
non-global in the
I see...the only reason I saw to switch to relative branches is that it
avoids the need to distinguish between ROM and non-ROM targets. I guess the
argument for their approach is that if your microcode flow is complex enough
to require a branch then it's probably complex enough to need to come
of the
combinational
decoder, so it's like you get one instruction at that point. Either that
one
instruction does the trick, or you need to go to the ROM where a micropc
conceptually exists.
Gabe
Quoting Steve Reinhardt [EMAIL PROTECTED]:
I see...the only reason I saw to switch to relative
If it's that complicated, why not just do it in C++ inside of M5, and have a
special microop that just calls that function and lets it do the dirty
work? I don't think performance fidelity is an issue here, and even if it
were, we could always just make that single microop take longer.
Steve
On
Collecting the necessary information in Python up front seems reasonable to
me.
As far as where the C++ code would go, it seems to me it could either be a
method on the BaseCPU object or a global function in the x86 ISA namespace.
The latter makes sense if we're trying not to pollute the CPU
I think keeping the register index type as part of the ISA makes sense: in
almost all conceivable cases a uint8_t is adequate, and when you're packing
several of these in each StaticInst it can really add up to poor cache
utilization, but forcing all future architectures to have at most 256 regs
I'm not sure how it's supposed to work (perhaps only Korey can answer that),
but I think the basic problem here is that memAccFlags is only defined in
the Memory subclass of MipsStaticInst while what you are trying to
dereference is a pointer to the base StaticInst class.
Steve
On Fri, Sep 26,
Why the double negative (!yield_mask != 0)? Seems like this should either
be !yield_mask or yield_mask == 0, but not something in between...
Steve
On Fri, Sep 26, 2008 at 3:29 PM, Nathan Binkert [EMAIL PROTECTED] wrote:
changeset eb5664be6075 in /z/repo/m5
details:
I thought that we had agreed to always use braces for control structures
(for, if, while, etc.) since that makes it easier to add/remove lines
without worrying about adding/removing braces too. I don't see it mentioned
either way on the coding style page, but I know I've developed the habit of
On Sat, Sep 27, 2008 at 9:35 PM, nathan binkert [EMAIL PROTECTED] wrote:
I think that sounds fine. Does no braces required also mean no braces
allowed, or is that something left up to the implementers discretion? I
think it should be optional rather than forbidden.
I'd agree with
-- Forwarded message --
From: Reinhardt, Steve [EMAIL PROTECTED]
Date: Tue, Sep 30, 2008 at 7:16 AM
Subject: FW: changeset in m5: Make overriding port assignments in Python
work,
To: [EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Great, glad you guys were able to do that.
There will be a
new flag on static insts which will indicate whether or not they leave
the context of the current macroop on faults.
Is this flag for microops or macroops or both?
Is this feature required only for the optimization cases you
Did you do an hg mv rename on the patch file? What happens if you try
creating both files (old and new) and then doing an hg rm on the one you
don't want?
Steve
On Mon, Oct 6, 2008 at 1:59 AM, Gabe Black [EMAIL PROTECTED] wrote:
I'm trying to commit my patch repository and push it up to
The official coding style is that names that are acronyms should be all
upper case (e.g., CPU):
http://m5sim.org/wiki/index.php/Coding_Style#Naming
Again, not that I have such a strong opinion either way, just seeking
consistency...
Steve
On Sat, Oct 11, 2008 at 2:26 AM, Gabe Black [EMAIL
well. Sorry about that.
Gabe
Steve Reinhardt wrote:
The official coding style is that names that are acronyms should be
all upper case (e.g., CPU):
http://m5sim.org/wiki/index.php/Coding_Style#Naming
Again, not that I have such a strong opinion either way, just seeking
consistency
Hi Gabe,
I haven't looked at all the code surrounding this in detail, but I think
this is unnecessary... packets really are messages (though up to now they've
all been coherence messages), and the idea behind Port objects is that in
the common case a MemObject should have a dedicated Port
I'd add that even for stats the cpu ID shouldn't be used much... the
stats that are associated with the cpu object will automatically be
associated with the correct cpu, and for just about everything outside
the cpu object that cares about tracking where something came from
(e.g., caches) we
There's also the possibility that these accesses could be atomic, right?
On Mon, Oct 27, 2008 at 5:33 PM, Gabe Black [EMAIL PROTECTED] wrote:
In the atomic simple CPU, they're broken up across the CPU's peers
blocksize aligned boundaries by the CPU and done as x different
accesses, usually 1
being atomic, so for x86 at
least atomicity is a larger, separate problem. I'm not sure about that
though. I'll see if I can find anything in the manuals.
Gabe
Steve Reinhardt wrote:
There's also the possibility that these accesses could be atomic, right?
On Mon, Oct 27, 2008 at 5:33 PM, Gabe
lines we're ensuring all the atomicity Intel
does.
The only tricky part is if something about the translation changes
halfway through an instruction, but I don't think there are any
guarantees about what's supposed to happen then anyway.
Gabe
Steve Reinhardt wrote:
OK... so if we have
You need to always call completeAcc() because it may do something
necessary... in the case of store conditional, it updates the
destination register that indicates to the program whether the store
succeeded or not. completeAcc() gets this information out of the
packet, so that's why you need to
know
what they can/can't expect, etc.
Gabe
Steve Reinhardt wrote:
You need to always call completeAcc() because it may do something
necessary... in the case of store conditional, it updates the
destination register that indicates to the program whether the store
succeeded
It's definitely a bug... it used to work. I wonder if it has
something to do with migrating towards a more realistic paging model
for SE mode (though that happened quite a while ago---August 2007
according to hg---and if that was totally broken I'm surprised no one
noticed it yet). I'd take a
EIO is Alpha only right now and will almost certainly remain so... not
because you couldn't port it to other ISAs, but if we decided we did
want to have an ISA-independent EIO-like capability we'd almost
certainly develop something else from scratch. The actual EIO code is
really there only for
changes to timing.cc to make sure this wasn't
something I did accidentally and it appears not, but that still may be
the case. If nobody does anything with this for a while I'll get to it,
but that might not happen quickly.
Gabe
Steve Reinhardt wrote:
You're right, it is the request
Yea, Ali's got it right... the way to think about address-based
routing on the bus is that the packet logically does get broadcast to
determine the destination; all our mucking with address ranges is
really just some combination of optimization and sanity check.
As far as the setSrc() calls in
On Wed, Nov 5, 2008 at 7:57 PM, nathan binkert [EMAIL PROTECTED] wrote:
Yea, Ali's got it right... the way to think about address-based
routing on the bus is that the packet logically does get broadcast to
determine the destination; all our mucking with address ranges is
really just some
signal on the bus
which prevents anyone else from using it while the sensitive instruction is
running. Normally the value would migrate up into the cache anyway where it
could then be locked, but the bus signal would still be necessary with
uncacheable accesses.
Gabe
Quoting Steve Reinhardt
What's the convention in other objects? I'm fine with either approach
(though I lean toward what Nate is suggesting); as with most style
things, I'm more concerned with consistency than anything else. I'd
be OK with this if it's part of a trend toward doing accessors in this
style globally (in
-r f693fcdd4aa5 -r 61c838ecc225 util/tracediff
--- a/util/tracediffThu Nov 06 11:11:50 2008 -0500
+++ b/util/tracediffThu Nov 06 20:23:05 2008 -0800
@@ -28,7 +28,9 @@
# Authors: Steve Reinhardt
# Script to simplify using rundiff on trace outputs from two
-# invocations of m5
references to packets
instead? It has a semantic implication that memory management is done
by the caller, and that the callee should never save the reference.
- Clint
On Nov 7, 2008, at 3:35 PM, Steve Reinhardt wrote:
Thanks for the detailed response. I agree that the explicit
Thanks, Gabe. It's cool to have this working. Just a few minor things:
- It looks like the two requests are issued to the cache
sequentially... did you consider issuing them concurrently? I don't
see a reason why this wouldn't work, though it would be a little more
complex (since the responses
On Sat, Nov 8, 2008 at 9:12 PM, Gabe Black [EMAIL PROTECTED] wrote:
- Would it be possible to condense the code a bit? I think doing
things a little more lockstep with the two requests would help; also
I'd think you can assume that both requests end up being the same in
terms of
Great feedback on the coding style... thanks. My main point was that
we should either follow the rule or get rid of it; sounds like
following it is the way to go.
Nate's comments point out a couple of holes:
- We don't really have a Python coding style (though the existing
style page doesn't
changeset dea5fcd1ead0 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=dea5fcd1ead0
description:
Cache: Refactor packet forwarding a bit.
Makes adding write-through operations easier.
diffstat:
2 files changed, 6 insertions(+), 7 deletions(-)
There's no predefined interface for this. You probably just want to
write directly into the CacheBlk fields (see src/mem/cache/blk.hh).
The readData and writeData methods on the Tags objects (such as LRU)
are obsolete and don't do what you want.
Steve
2008/11/13 srimugunthan dhandapani [EMAIL
If your getting an assertion failure in the chunk generator, it's
probably (partially) my fault... I added an assertion there (totalSize
= 0) that would have caught a painful bug I had to track down much
earlier, and just ran the quick regressions on it.
I think that assertion is probably now
changeset d7540fa81f1d in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=d7540fa81f1d
description:
Cache: get rid of obsolete Tag methods.
I think readData() and writeData() were used for Erik's compression
work, but that code is gone, these aren't called
changeset f28f020f3006 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=f28f020f3006
description:
syscalls: fix latent brk/obreak bug.
Bogus calls to ChunkGenerator with negative size were triggering
a new assertion that was added there.
Also did a
I just confirmed that
SPARC_SE/tests/opt/long/70.twolf/sparc/linux/simple-timing includes a
brk() call that tries to shrink the heap, which with the old
obreakFunc() triggers the ChunkGenerator assertion I added.
It turns out that in the old broken code if the previous break val was
at a page
1 - 100 of 977 matches
Mail list logo
