Re: [m5-dev] Cron /z/m5/regression/do-regression --scratch all

[Gabe Black]

Does anyone have any ideas about when X86_SE parser stopped working? The
last time it passed for sure was the end of February, but on March 16th
Ali updated the stats and so it was presumably working then too. I'm
running at that changeset right now to confirm that. There weren't any
X86 specific changes recently, but there were a few O3 ones which might
have changed the stats. The output is below, and you can see the biggest
change percentage wise was icache writebacks. Most of the changes are
related to memory somehow. After the stats is info about a change that
may have caused the problem.

= Statistics differences =
Maximum error magnitude: +133.33%

  Reference  New Value   Abs Diff   Pct Chg
Key statistics:

  host_inst_rate 189714 148502 -41212   -21.72%
  host_mem_usage 264736 268256   3520+1.33%
  sim_insts  1527476062 15289887561512694+0.10%
  sim_ticks  610952992000 612245337000 1292345000   
+0.21%
  system.cpu.commit.COM:count1527476062 15289887561512694+0.10%

Differences > 0%:

  system.cpu.icache.writebacks3  7  4  +133.33%
  system.cpu.rename.RENAME:serializeStallCycles  19936 
16025  -3911   -19.62%
  system.cpu.l2cache.occ_%::0  0.213694   0.236362   0.022668   +10.61%
  system.cpu.l2cache.occ_blocks::0 7002.339473 7745.103692 742.764219  
+10.61%
  system.cpu.rename.RENAME:tempSerializingInsts   2561  
2314   -247-9.64%
  system.cpu.icache.ReadReq_mshr_hits   1570   1427  
-143-9.11%
  system.cpu.icache.demand_mshr_hits   1570   1427   -143   
-9.11%
  system.cpu.icache.overall_mshr_hits   1570   1427  
-143-9.11%
  system.cpu.rename.RENAME:serializingInsts   2550   2345  
-205-8.04%
  system.cpu.l2cache.ReadReq_misses 316709 339091  22382   
+7.07%
  system.cpu.l2cache.ReadReq_mshr_misses 316709 339091 
22382+7.07%
  system.cpu.l2cache.ReadReq_mshr_miss_latency 9818903000 10512799000 
693896000+7.07%
  system.cpu.l2cache.ReadReq_miss_latency 10822415500 11584355000 
761939500+7.04%
  system.cpu.dcache.ReadReq_mshr_miss_latency 14062264500 14863694500 
80143+5.70%
  system.cpu.l2cache.ReadReq_miss_rate   0.182786   0.192941  
0.010155+5.56%
  system.cpu.l2cache.ReadReq_mshr_miss_rate   0.182786   0.192941  
0.010155+5.56%
  system.cpu.idleCycles24586339   256777931091454+4.44%
  system.cpu.dcache.ReadReq_avg_mshr_miss_latency 8150.695480
8493.787248 343.091768+4.21%
  system.cpu.l2cache.replacements 553099 575827  22728+4.11%
  system.cpu.l2cache.demand_mshr_miss_latency 17475146000 18186565000 
711419000+4.07%
[... showing top 20 errors only, additional errors omitted ...]

* build/X86_SE/tests/fast/long/20.parser/x86/linux/o3-timing FAILED!

changeset 9f704aa10eb4 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9f704aa10eb4
description:
O3: Fix unaligned stores when cache blocked

Without this change the a store can be issued to the cache multiple 
times.
If this case occurs when the l1 cache is out of mshrs (and thus blocked)
the processor will never make forward progress because each cycle it 
will
send a single request using the recently freed mshr and not completing 
the
multipart store. This will continue forever.

diffstat:

 src/cpu/o3/lsq_unit_impl.hh |  4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diffs (14 lines):

diff -r 2af262e73961 -r 9f704aa10eb4 src/cpu/o3/lsq_unit_impl.hh
--- a/src/cpu/o3/lsq_unit_impl.hh   Thu Mar 17 00:43:54 2011 -0400
+++ b/src/cpu/o3/lsq_unit_impl.hh   Thu Mar 17 19:20:19 2011 -0500
@@ -1103,7 +1103,9 @@
 dynamic_cast(retryPkt->senderState);
 
 // Don't finish the store unless this is the last packet.
-if (!TheISA::HasUnalignedMemAcc || !state->pktToSend) {
+if (!TheISA::HasUnalignedMemAcc || !state->pktToSend ||
+state->pendingPacket == retryPkt) {
+state->pktToSend = false;
 storePostSend(retryPkt);
 }
 retryPkt = NULL;
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev



On 04/03/11 09:44, Cron Daemon wrote:
> * build/X86_SE/tests/fast/long/20.parser/x86/linux/o3-timing FAILED!
> * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic 
> passed.
> * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby 
> passed.
> * build/ALPHA_SE/tests/fast/long/50.vortex/alpha/tru64/simple-timing 
> passed.
> * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby 
> passed.
> * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio

Re: [m5-dev] Review Request: patch from Vince Weaver for review

[Gabe Black]

> On 2011-03-18 13:54:12, Gabe Black wrote:
> > It seems like we should be able to emulate the access system call fairly 
> > easily. It basically just checks if a file can be accessed in certain ways, 
> > I think. We could do that on the real file descriptor, rearrange the result 
> > if necessary, and pass it back. The other syscall changes here look ok.
> 
> Lisa Hsu wrote:
> Would you object to committing/pushing as is and emulating access() if it 
> ever becomes necessary in the future?  It's not something I'm going to commit 
> to doing, and I wouldn't want everything else to get held up because of it.
> 
> Gabe Black wrote:
> How is access() being used right now? It would be dangerous to assume 
> just because it didn't seem to cause a problem by ignoring it that it's 
> actually safe to do so, and it must be used by something or that line 
> wouldn't be necessary. I would rather we did this safely than expediently. 
> This change, or at least that line, should be independent of any other change 
> as far as I've seen and shouldn't hold anything else up.
> 
> Ali Saidi wrote:
> well... all it seems like you would need to do is return 0 when it's 
> called. That means you can access the file and I doubt we would ever have a 
> case where you couldn't.

That sounds about right, and that should be really easy to implement. We should 
make sure we put a comment in there explaining why we're always returning 0.


- Gabe


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/588/#review980
---


On 2011-03-17 16:05:56, Lisa Hsu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/588/
> ---
> 
> (Updated 2011-03-17 16:05:56)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> X86:  SE syscalls: patch from Vince Weaver for review
> 
> 
> Diffs
> -
> 
>   src/arch/x86/linux/syscalls.cc 2e269d6fb3e6 
> 
> Diff: http://reviews.m5sim.org/r/588/diff
> 
> 
> Testing
> ---
> 
> I've done minimal testing on these, i.e. I've pushed them to a clean tree and 
> run X86 SPEC2k6 binaries on them, some of which didn't work prior to the 
> patches but now do.  Others remain broken.  Vince, however, has done lots of 
> testing and basically needed these to run SPEC2K workloads to completion for 
> his thesis.  In other words, I bet these patches are good, but not complete 
> for the purposes of running SPEC2k6.
> 
> 
> Thanks,
> 
> Lisa
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: patch from Vince Weaver for review

[Ali Saidi]

> On 2011-03-18 13:54:12, Gabe Black wrote:
> > It seems like we should be able to emulate the access system call fairly 
> > easily. It basically just checks if a file can be accessed in certain ways, 
> > I think. We could do that on the real file descriptor, rearrange the result 
> > if necessary, and pass it back. The other syscall changes here look ok.
> 
> Lisa Hsu wrote:
> Would you object to committing/pushing as is and emulating access() if it 
> ever becomes necessary in the future?  It's not something I'm going to commit 
> to doing, and I wouldn't want everything else to get held up because of it.
> 
> Gabe Black wrote:
> How is access() being used right now? It would be dangerous to assume 
> just because it didn't seem to cause a problem by ignoring it that it's 
> actually safe to do so, and it must be used by something or that line 
> wouldn't be necessary. I would rather we did this safely than expediently. 
> This change, or at least that line, should be independent of any other change 
> as far as I've seen and shouldn't hold anything else up.

well... all it seems like you would need to do is return 0 when it's called. 
That means you can access the file and I doubt we would ever have a case where 
you couldn't. 


- Ali


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/588/#review980
---


On 2011-03-17 16:05:56, Lisa Hsu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/588/
> ---
> 
> (Updated 2011-03-17 16:05:56)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> X86:  SE syscalls: patch from Vince Weaver for review
> 
> 
> Diffs
> -
> 
>   src/arch/x86/linux/syscalls.cc 2e269d6fb3e6 
> 
> Diff: http://reviews.m5sim.org/r/588/diff
> 
> 
> Testing
> ---
> 
> I've done minimal testing on these, i.e. I've pushed them to a clean tree and 
> run X86 SPEC2k6 binaries on them, some of which didn't work prior to the 
> patches but now do.  Others remain broken.  Vince, however, has done lots of 
> testing and basically needed these to run SPEC2K workloads to completion for 
> his thesis.  In other words, I bet these patches are good, but not complete 
> for the purposes of running SPEC2k6.
> 
> 
> Thanks,
> 
> Lisa
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: X86: rlimit: Another patch from Vince Weaver

[Gabe Black]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/591/#review1097
---



src/arch/x86/linux/linux.hh


These RUSAGE and RLIMIT constants come from generic header files in Linux, 
not one specific to X86. If they aren't there already, they should be in a base 
class, not an x86 (or especially a 64 bit x86) subclass.



src/arch/x86/linux/linux.hh


This constant is wrong according to 
http://lxr.linux.no/linux+*/include/asm-generic/resource.h#L26. This should be 
NPROC. Similarly 7 is NOFILE, 8 is MEMLOCK, and 9 is AS (VMEM doesn't seem to 
exist). There are some others which have been left out.



src/arch/x86/linux/linux.hh


The indentation here is off.



src/arch/x86/linux/linux.hh


These constants also need to be fixed, or removed if the 64 bit versions 
get promoted to a base class.


- Gabe


On 2011-03-17 16:06:30, Lisa Hsu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/591/
> ---
> 
> (Updated 2011-03-17 16:06:30)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> X86:  rlimit: Another patch from Vince Weaver
> 
> 
> Diffs
> -
> 
>   src/arch/x86/linux/linux.hh 2e269d6fb3e6 
>   src/arch/x86/linux/syscalls.cc 2e269d6fb3e6 
> 
> Diff: http://reviews.m5sim.org/r/591/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Lisa
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: X86: haddps: Another patch from Vince Weaver

[Gabe Black]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/592/#review1096
---



src/arch/x86/isa/insts/simd128/floating_point/arithmetic/horizontal_addition.py


ext is no longer set to a raw bitvector that selects per instruction 
features like this since, as you can see, it's pretty opaque just looking at 
it. The maddf ext=1 becomes ext=Scalar. For msrli and mslli, ext=0 is the 
default and can be dropped. It would leave the ops as SIMD. Since they're 
already operating at the full width of the fp register type (a double) the 
value is especially redundant.



src/arch/x86/isa/insts/simd128/floating_point/arithmetic/horizontal_addition.py


This implementation is a bit inefficient, although not terribly so. You 
have to be careful since the two operands may be the same registers and you 
don't want to overwrite something you still need, but, for instance, the maddf 
one line above, this shift of ufp4 and the maddf on line 60 could all update 
xmmh since all "high" halves of xmm registers have been read and no faults can 
happen. The moves that read out xmmlm could be moved higher, and xmml could 
also be updated directly.

I think it -may- also be possible to do something clever and cut down the 
number of microops shifting things around to pack and unpack the results. I may 
have also suspected this was true when I wrote the much simpler 64 bit wide 
version of this instruction below this one where the components are whole 
registers and can be indexed directly, but then didn't come up with anything 
and punted for later.



src/arch/x86/isa/insts/simd128/floating_point/arithmetic/horizontal_addition.py


This microop is changing architecturally visible state and effectively 
committing to completing the op before all the possibly faulting ops have 
executed, specifically the following loads. There are 8 microcode fp registers 
so you can just use the others and leave ufp3 around until the end.



src/arch/x86/isa/insts/simd128/floating_point/arithmetic/horizontal_addition.py


Like above, this can't happen before the loads.


- Gabe


On 2011-03-17 16:07:08, Lisa Hsu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/592/
> ---
> 
> (Updated 2011-03-17 16:07:08)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> X86:  haddps: Another patch from Vince Weaver
> 
> 
> Diffs
> -
> 
>   src/arch/x86/isa/decoder/two_byte_opcodes.isa 2e269d6fb3e6 
>   
> src/arch/x86/isa/insts/simd128/floating_point/arithmetic/horizontal_addition.py
>  2e269d6fb3e6 
> 
> Diff: http://reviews.m5sim.org/r/592/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Lisa
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: X86: fsincos: Another patch from Vince Weaver

[Gabe Black]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/593/#review1095
---


We never really did decide how we wanted to structure the microops for x87, but 
this seems reasonable at least to start with. The structure of the microop 
definitions need to be cleaned up a little.


src/arch/x86/isa/microops/fpop.isa


Cosfp, Sinfp and the existing Movfp could all inherit from a base class 
(FpUniOp for unary for instance) that has this other form of __init__. Then 
they wouldn't each define an essentially identical copy.


- Gabe


On 2011-03-17 16:07:17, Lisa Hsu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/593/
> ---
> 
> (Updated 2011-03-17 16:07:17)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> X86:  fsincos: Another patch from Vince Weaver
> 
> 
> Diffs
> -
> 
>   src/arch/x86/isa/decoder/x87.isa 2e269d6fb3e6 
>   
> src/arch/x86/isa/insts/x87/transcendental_functions/trigonometric_functions.py
>  2e269d6fb3e6 
>   src/arch/x86/isa/microops/fpop.isa 2e269d6fb3e6 
> 
> Diff: http://reviews.m5sim.org/r/593/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Lisa
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: X86: fnstsw: Another patch from Vince Weaver

[Gabe Black]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/594/#review1094
---



src/arch/x86/isa/insts/x87/control/save_x87_status_word.py


Since FSTSW isn't an instruction it doesn't need to be mentioned.



src/arch/x86/isa/insts/x87/control/save_x87_status_word.py


This information isn't useful here and shouldn't clutter the instruction 
definition.



src/arch/x86/isa/insts/x87/control/save_x87_status_word.py


Reading the status register should automatically fold in the top register. 
If it doesn't it should. That shouldn't be implemented with microcode. Also, 
the string constants naming these registers can be set up in 
arch/x86/isa/microasm.isa by appending them to the "assembler.symbols" dict. 
Then they'll show up in the scope of the microcode and you can use "rdval t1, 
fsw"

With those changes, there's also no reason to construct the value in a 
temporary microcode register t1 in the AX case (FNSTSW_R).



src/arch/x86/isa/insts/x87/control/save_x87_status_word.py


datasize will already be 2 because of the rAw operand. The w is interpreted 
as "word sized" which means datasize is set to 2 bytes. That's what I remember 
and what looking at the code seems to confirm, but it's been a while so let me 
know if you know that's not true.



src/arch/x86/isa/operands.isa


This is never used and shouldn't be added.



src/arch/x86/regs/misc.hh


This already exists as MISCREG_FSW. MISCREG_FCW is the control word, and 
MISCREG_FTW is the tag word.


- Gabe


On 2011-03-17 16:07:24, Lisa Hsu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/594/
> ---
> 
> (Updated 2011-03-17 16:07:24)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> X86:  fnstsw: Another patch from Vince Weaver
> 
> 
> Diffs
> -
> 
>   src/arch/x86/isa/decoder/x87.isa 2e269d6fb3e6 
>   src/arch/x86/isa/insts/x87/control/save_x87_status_word.py 2e269d6fb3e6 
>   src/arch/x86/isa/operands.isa 2e269d6fb3e6 
>   src/arch/x86/regs/misc.hh 2e269d6fb3e6 
> 
> Diff: http://reviews.m5sim.org/r/594/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Lisa
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: X86 ioctl: Another patch from Vince Weaver

[Gabe Black]

> On 2011-03-18 13:57:35, Gabe Black wrote:
> > src/sim/syscall_emul.hh, line 503
> > 
> >
> > Why is this change necessary? I'm not 100% sure why it was the way it 
> > was before, but I see no reason to change it either. Changing the fatal to 
> > a warn may be necessary to get some benchmark to run, but I'm talking 
> > specifically about the ones that would return -ENOTTY.
> 
> Vince Weaver wrote:
> It's been a while, but let's see if I can see what's going on.
> 
> Before we had a short list of ioctls we return -ENOTTY for, any not on 
> the list gave a fatal error.
> 
> ENOTTY if I recall correctly is the typical way the kernel reports an 
> ioctl not being implemented.  So by changing all ioctls to warn and then 
> report ENOTTY we are saying that we don't support it, but the program can 
> keep running assuming it handles an ENOTTY properly.
> 
> For most of the SPEC benchmarks ioctl() calls aren't important for 
> correctness, so this works.  
> 
> We could go back to having a whitelist of known-to-be-OK-to-ignore 
> ioctls(), but it might turn out to be a lengthy list, and also we probably 
> should implement things like isatty() properly as I do think some benchmarks 
> depend on it returning the right value
> (see http://www.cs.binghamton.edu/~msim/wiki/index.php/TIOCISATTY )
>
> 
> Gabe Black wrote:
> isatty is actually pretty annoying, and it's important that it -not- 
> always return the right answer. It needs to be consistent regardless of 
> whether your piping output to a file or watching it on the console so runs 
> are deterministic, and if it always thinks it's going to a tty it'll buffer 
> properly for when it's actually going to a tty (and doesn't look like 
> something's broken, basically) and just perform a little worse when it's not. 
> As far as simulator performance it doesn't matter since I'm sure it's a long 
> way from being the critical path, and it should be a reasonable situation as 
> far as simulated performance.
> 
> I think a whitelist is a good idea, and we don't have to have -all- the 
> ok to ignore ones on there, just the ok to ignore ones that actually get 
> called. That should be a lot more manageable list. That way you know if 
> something out of the ordinary is happening (the simulator will bomb out) 
> rather than something weird happening and the benchmark stumbling on to 
> eventually die, potentially far from evidence of what happened. The later is 
> a lot harder to debug.
> 
> Steve Reinhardt wrote:
> ENOTTY is just the way the kernel reports a TTY-specific ioctl being 
> invoked on a non-TTY device.  Gabe is right that for repeatability you always 
> want the simulator to always act like there's no tty for determinism.  I 
> would prefer to see us figure out what other ioctls need to be added to the 
> TTY-specific list than to make a blanket assumption that any ioctl that's 
> called is TTY-specific.
> 
> Lisa Hsu wrote:
> So, what's the consensus here?  No checkin until ioctls are better 
> figured out?

The change to syscalls.cc is fine since that's just hooking up the existing 
syscall functions and there isn't anything unusual or objectionable about how 
that's being done. The change to syscall_emul.hh is not correct as far as I can 
tell. If there are specific IOCTL constants that are being used, we'll need to 
find out what those are and then what to do with them.


- Gabe


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/589/#review981
---


On 2011-03-17 16:06:13, Lisa Hsu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/589/
> ---
> 
> (Updated 2011-03-17 16:06:13)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> X86 ioctl:  Another patch from Vince Weaver
> 
> 
> Diffs
> -
> 
>   src/arch/x86/linux/syscalls.cc 2e269d6fb3e6 
>   src/sim/syscall_emul.hh 2e269d6fb3e6 
> 
> Diff: http://reviews.m5sim.org/r/589/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Lisa
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: patch from Vince Weaver for review

[Gabe Black]

> On 2011-03-18 13:54:12, Gabe Black wrote:
> > It seems like we should be able to emulate the access system call fairly 
> > easily. It basically just checks if a file can be accessed in certain ways, 
> > I think. We could do that on the real file descriptor, rearrange the result 
> > if necessary, and pass it back. The other syscall changes here look ok.
> 
> Lisa Hsu wrote:
> Would you object to committing/pushing as is and emulating access() if it 
> ever becomes necessary in the future?  It's not something I'm going to commit 
> to doing, and I wouldn't want everything else to get held up because of it.

How is access() being used right now? It would be dangerous to assume just 
because it didn't seem to cause a problem by ignoring it that it's actually 
safe to do so, and it must be used by something or that line wouldn't be 
necessary. I would rather we did this safely than expediently. This change, or 
at least that line, should be independent of any other change as far as I've 
seen and shouldn't hold anything else up.


- Gabe


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/588/#review980
---


On 2011-03-17 16:05:56, Lisa Hsu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/588/
> ---
> 
> (Updated 2011-03-17 16:05:56)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> X86:  SE syscalls: patch from Vince Weaver for review
> 
> 
> Diffs
> -
> 
>   src/arch/x86/linux/syscalls.cc 2e269d6fb3e6 
> 
> Diff: http://reviews.m5sim.org/r/588/diff
> 
> 
> Testing
> ---
> 
> I've done minimal testing on these, i.e. I've pushed them to a clean tree and 
> run X86 SPEC2k6 binaries on them, some of which didn't work prior to the 
> patches but now do.  Others remain broken.  Vince, however, has done lots of 
> testing and basically needed these to run SPEC2K workloads to completion for 
> his thesis.  In other words, I bet these patches are good, but not complete 
> for the purposes of running SPEC2k6.
> 
> 
> Thanks,
> 
> Lisa
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: Ruby: Add support for functional accesses

[Brad Beckmann]

> On 2011-03-31 22:08:21, Brad Beckmann wrote:
> > This looks great, I just have a few minor suggestions below.
> > 
> > It seems like the next step is to figure out how to deal with functional 
> > accesses not succeeding in the CPUs and devices.
> 
> Nilay Vaish wrote:
> Brad, I would make the changes you have listed below. I also need to add
> code for directory memory accesses. Can you elaborate on the next step 
> you 
> mentioned? We are yet not dealing with the devices, I believe.
> 
> Nilay Vaish wrote:
> One more question for you. Do we need functional access support for the 
> PioPort
> as well? We do not have it currently.

Yes, eventually if we want Ruby to supply data in FS mode, RubyPort will need 
to support functional access from the PioPort to Ruby memory.  It is up to you 
whether you want to implement that support now, or first make sure functional 
accesses are working SE mode.  If you want to make sure SE mode functional 
accesses work, first modify the ruby mem tester to issue functional access 
(right now that is hardcoded off).  Also you should try a few binaries under SE 
mode, like "hello world".  


- Brad


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/611/#review1082
---


On 2011-04-02 11:42:47, Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/611/
> ---
> 
> (Updated 2011-04-02 11:42:47)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> Ruby: Add support for functional accesses
> This patch is meant for aiding discussions on implementation of functional
> access support in Ruby.
> 
> 
> Diffs
> -
> 
>   configs/ruby/MESI_CMP_directory.py aeec9e157d06 
>   configs/ruby/Ruby.py aeec9e157d06 
>   src/mem/ruby/network/Network.cc aeec9e157d06 
>   src/mem/ruby/network/Network.py aeec9e157d06 
>   src/mem/ruby/profiler/Profiler.cc aeec9e157d06 
>   src/mem/ruby/profiler/Profiler.py aeec9e157d06 
>   src/mem/ruby/recorder/Tracer.cc aeec9e157d06 
>   src/mem/ruby/recorder/Tracer.py aeec9e157d06 
>   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
>   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
>   src/mem/ruby/system/Cache.py aeec9e157d06 
>   src/mem/ruby/system/CacheMemory.hh aeec9e157d06 
>   src/mem/ruby/system/CacheMemory.cc aeec9e157d06 
>   src/mem/ruby/system/DirectoryMemory.hh aeec9e157d06 
>   src/mem/ruby/system/DirectoryMemory.cc aeec9e157d06 
>   src/mem/ruby/system/DirectoryMemory.py aeec9e157d06 
>   src/mem/ruby/system/RubyPort.hh aeec9e157d06 
>   src/mem/ruby/system/RubyPort.cc aeec9e157d06 
>   src/mem/ruby/system/RubySystem.py aeec9e157d06 
>   src/mem/ruby/system/SConscript aeec9e157d06 
>   src/mem/ruby/system/Sequencer.cc aeec9e157d06 
>   src/mem/ruby/system/Sequencer.py aeec9e157d06 
>   src/mem/ruby/system/System.hh aeec9e157d06 
>   src/mem/ruby/system/System.cc aeec9e157d06 
> 
> Diff: http://reviews.m5sim.org/r/611/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nilay
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: Ruby: Add support for functional accesses

[Brad Beckmann]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/611/#review1090
---



src/mem/ruby/system/DirectoryMemory.py


Why are you deleting this file and where are you moving the current 
functionality?


- Brad


On 2011-04-02 11:42:47, Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/611/
> ---
> 
> (Updated 2011-04-02 11:42:47)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> Ruby: Add support for functional accesses
> This patch is meant for aiding discussions on implementation of functional
> access support in Ruby.
> 
> 
> Diffs
> -
> 
>   configs/ruby/MESI_CMP_directory.py aeec9e157d06 
>   configs/ruby/Ruby.py aeec9e157d06 
>   src/mem/ruby/network/Network.cc aeec9e157d06 
>   src/mem/ruby/network/Network.py aeec9e157d06 
>   src/mem/ruby/profiler/Profiler.cc aeec9e157d06 
>   src/mem/ruby/profiler/Profiler.py aeec9e157d06 
>   src/mem/ruby/recorder/Tracer.cc aeec9e157d06 
>   src/mem/ruby/recorder/Tracer.py aeec9e157d06 
>   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
>   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
>   src/mem/ruby/system/Cache.py aeec9e157d06 
>   src/mem/ruby/system/CacheMemory.hh aeec9e157d06 
>   src/mem/ruby/system/CacheMemory.cc aeec9e157d06 
>   src/mem/ruby/system/DirectoryMemory.hh aeec9e157d06 
>   src/mem/ruby/system/DirectoryMemory.cc aeec9e157d06 
>   src/mem/ruby/system/DirectoryMemory.py aeec9e157d06 
>   src/mem/ruby/system/RubyPort.hh aeec9e157d06 
>   src/mem/ruby/system/RubyPort.cc aeec9e157d06 
>   src/mem/ruby/system/RubySystem.py aeec9e157d06 
>   src/mem/ruby/system/SConscript aeec9e157d06 
>   src/mem/ruby/system/Sequencer.cc aeec9e157d06 
>   src/mem/ruby/system/Sequencer.py aeec9e157d06 
>   src/mem/ruby/system/System.hh aeec9e157d06 
>   src/mem/ruby/system/System.cc aeec9e157d06 
> 
> Diff: http://reviews.m5sim.org/r/611/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nilay
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Cron /z/m5/regression/do-regression --scratch all

[Cron Daemon]

* build/X86_SE/tests/fast/long/20.parser/x86/linux/o3-timing FAILED!
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby 
passed.
* build/ALPHA_SE/tests/fast/long/50.vortex/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/fast/long/00.gzip/alpha/tru64/simple-atomic passed.
* build/ALPHA_SE/tests/fast/long/30.eon/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing 
passed.
* build/ALPHA_SE/tests/fast/long/30.eon/alpha/tru64/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp 
passed.
* build/ALPHA_SE/tests/fast/long/50.vortex/alpha/tru64/o3-timing passed.
* build/ALPHA_SE/tests/fast/long/70.twolf/alpha/tru64/inorder-timing passed.
* build/ALPHA_SE/tests/fast/long/50.vortex/alpha/tru64/simple-atomic passed.
* build/ALPHA_SE/tests/fast/long/70.twolf/alpha/tru64/simple-atomic passed.
* build/ALPHA_SE/tests/fast/long/70.twolf/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/fast/long/00.gzip/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic 
passed.
* build/ALPHA_SE/tests/fast/long/60.bzip2/alpha/tru64/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA_SE/tests/fast/long/40.perlbmk/alpha/tru64/simple-atomic 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA_SE/tests/fast/long/00.gzip/alpha/tru64/o3-timing passed.
* build/ALPHA_SE/tests/fast/long/60.bzip2/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/fast/long/30.eon/alpha/tru64/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA_SE/tests/fast/long/50.vortex/alpha/tru64/inorder-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA_SE/tests/fast/long/40.perlbmk/alpha/tru64/simple-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed.
* build/ALPHA_SE/tests/fast/long/70.twolf/alpha/tru64/o3-timing passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
 passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsu

Re: [m5-dev] Review Request: Ruby: Add support for functional accesses

[Nilay Vaish]

> On 2011-03-31 22:08:21, Brad Beckmann wrote:
> > This looks great, I just have a few minor suggestions below.
> > 
> > It seems like the next step is to figure out how to deal with functional 
> > accesses not succeeding in the CPUs and devices.
> 
> Nilay Vaish wrote:
> Brad, I would make the changes you have listed below. I also need to add
> code for directory memory accesses. Can you elaborate on the next step 
> you 
> mentioned? We are yet not dealing with the devices, I believe.

One more question for you. Do we need functional access support for the PioPort
as well? We do not have it currently.


- Nilay


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/611/#review1082
---


On 2011-04-02 11:42:47, Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/611/
> ---
> 
> (Updated 2011-04-02 11:42:47)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> Ruby: Add support for functional accesses
> This patch is meant for aiding discussions on implementation of functional
> access support in Ruby.
> 
> 
> Diffs
> -
> 
>   configs/ruby/MESI_CMP_directory.py aeec9e157d06 
>   configs/ruby/Ruby.py aeec9e157d06 
>   src/mem/ruby/network/Network.cc aeec9e157d06 
>   src/mem/ruby/network/Network.py aeec9e157d06 
>   src/mem/ruby/profiler/Profiler.cc aeec9e157d06 
>   src/mem/ruby/profiler/Profiler.py aeec9e157d06 
>   src/mem/ruby/recorder/Tracer.cc aeec9e157d06 
>   src/mem/ruby/recorder/Tracer.py aeec9e157d06 
>   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
>   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
>   src/mem/ruby/system/Cache.py aeec9e157d06 
>   src/mem/ruby/system/CacheMemory.hh aeec9e157d06 
>   src/mem/ruby/system/CacheMemory.cc aeec9e157d06 
>   src/mem/ruby/system/DirectoryMemory.hh aeec9e157d06 
>   src/mem/ruby/system/DirectoryMemory.cc aeec9e157d06 
>   src/mem/ruby/system/DirectoryMemory.py aeec9e157d06 
>   src/mem/ruby/system/RubyPort.hh aeec9e157d06 
>   src/mem/ruby/system/RubyPort.cc aeec9e157d06 
>   src/mem/ruby/system/RubySystem.py aeec9e157d06 
>   src/mem/ruby/system/SConscript aeec9e157d06 
>   src/mem/ruby/system/Sequencer.cc aeec9e157d06 
>   src/mem/ruby/system/Sequencer.py aeec9e157d06 
>   src/mem/ruby/system/System.hh aeec9e157d06 
>   src/mem/ruby/system/System.cc aeec9e157d06 
> 
> Diff: http://reviews.m5sim.org/r/611/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nilay
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Ruby Optimization Opportunity?

[Nilay Vaish]

On Fri, 1 Apr 2011, Korey Sewell wrote:


That's a good point.

I'll coordinate with Nilay offline to get him the right image.

Nilay, from your previous optimizations trials, where did you see most of
the simulation time being sent at?

On Fri, Apr 1, 2011 at 4:48 PM, Ali Saidi  wrote:


None of those benchmarks probably push the memory system with multiple
cores like fft. Why don't you give Nilay your fft benchmark?

Ali





Korey, I normally only run Ruby random tester to profile which parts of 
Ruby take most of the time. My observation was that wakeup() function for

the L1 cache controller takes most of the time (about 10%). It would be
good if you can provide me with the benchmark, I will investigate where
the time is being spent and hopefully, we would be able to speed up the
simulation.

Thanks
Nilay


___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev