Re: [gem5-dev] nightly regressions

2017-04-04 Thread Steve Reinhardt 
Here's the changeset Andreas was referring to:

http://repo.gem5.org/gem5?cmd=changeset;node=b2720503a978


On Tue, Apr 4, 2017 at 9:20 AM, Gabe Black  wrote:

> I can't add reviewers due to a known issue, but here is the stack of CLs
> which fix the regressions:
>
> https://gem5-review.googlesource.com/#/c/2641/
>
> Gabe
>
> On Tue, Apr 4, 2017 at 3:35 AM, Gabe Black  wrote:
>
> > Oh, also, the problem with EIO I think is not because there are EIO
> > regressions, it's that the EIO code is being added in with EXTRAS and
> > breaking the build for certain targets. Excluding it would be fairly
> > trivial if I had write permission for the regression script on zizzer.
> >
> > Gabe
> >
> > On Tue, Apr 4, 2017 at 3:32 AM, Gabe Black  wrote:
> >
> >> Yeah, there are a lot of problems with the current system. It has three
> >> real functions:
> >>
> >> 1. Making sure things run from end to end without crashing.
> >> 2. Checking for inadvertent changes to the stats.
> >> 3. Checking for non-determinstic behavior.
> >>
> >> Unfortunately it takes a really long time to run, doesn't distinguish
> >> between trivial and non-trivial divergence in behavior, is really hard
> to
> >> merge, doesn't tell you what's not working if something is broken, has
> >> dependencies with major complications, isn't very useful when people
> >> diverge from upstream, etc.
> >>
> >> I think there is definitely a role for that sort of test since those are
> >> meaningful, but then there are lots and lots of potential testing that
> >> we're not doing. We should have the few unit tests that already exist
> all
> >> either pass or fail, not just output something, and then make them
> >> easy/automatic to run, and we should have more of them. There are vast
> >> swathes of functionality that really should be tested with unit tests
> like:
> >>
> >> 1. The CPU models.
> >> 2. All the instructions for all the ISAs.
> >> 3. All the Device models.
> >> etc. etc.
> >>
> >> The amount of work it would/will take to cover the gap in testing is
> >> enormous, but in my opinion that's the technical debt that has to be
> paid
> >> down to straighten things out.
> >>
> >> Gabe
> >>
> >> On Tue, Apr 4, 2017 at 2:55 AM, Andreas Sandberg <
> >> andreas.sandb...@arm.com> wrote:
> >>
> >>> On 01/04/2017 12:27, Gabe Black wrote:
> >>>
>  Hi folks. I'm working through the nightly regressions to get them to a
>  good
>  point for a rebase of our internal branch of gem5, and I've noticed a
>  few
>  things:
> 
>  1. The stats have been changed but not updated a bunch of times. I've
>  identified almost all the points this has happened since the
> references
>  were last updated, and have patches which fix them. Some stat changes
>  are a
>  little fishy, but I'll at least identify the guilty change(s) so that
>  their
>  authors can look them over.
> 
> >>>
> >>> This is really hard to get right with the current system of "push to
> >>> submit". I would really like to avoid including stat updates in normal
> >>> code submissions. It would make it really hard to automatically submit
> >>> code (there would be stat conflicts for every single non-trivial
> change)
> >>> and it'd make cherry-picking really annoying.
> >>>
> >>> Ideally, the CI system should compare the stat output after applying a
> >>> CL to the previous stat update. That way, you can easily spot the
> >>> difference when submitting new code.
> >>>
> >>> 2. The SPARC FS regression were just plain not running because its
>  configuration had been broken. I'll have a patch to fix this.
>  3. The nightly regressions are still checking gem5 out from mercurial.
> 
> >>>
> >>> We should obviously fix this. However, the repo is kept in sync with
> the
> >>> golden git repo using a cron, so it's not quite as bad as it seems.
> >>>
> >>> 4. The "encumbered" repository has, as far as I can tell, not be
>  converted
>  from mercurial to git. Probably this isn't a problem because this code
>  is
>  mostly unchanging and becoming less relevant over time, especially
> since
>  EIO support was removed from the process classes (it was, right?).
>  5. The EIO code is also broken, because it tries to call "fatal" with
> a
>  "(void)" cast in front of it in a ternary operation. Something like
>  "foo ?
>  (void)fatal("a bad thing happened") : (void)fatal("a different bad
> thing
>  happened")". What "fatal" expands to now is apparently not compatible
>  with
>  this usage. Since I can access the encumbered repository, I can
> attempt
>  to
>  fix this.
>  I can (and in at least in some cases will) fix most of these issues,
>  except
>  maybe 4 if we still want encumbered to exist. Please speak up if I've
>  misinterpreted something or am missing some important bit of context.
>  [1]

Re: [gem5-dev] nightly regressions

2017-04-04 Thread Gabe Black 
I can't add reviewers due to a known issue, but here is the stack of CLs
which fix the regressions:

https://gem5-review.googlesource.com/#/c/2641/

Gabe

On Tue, Apr 4, 2017 at 3:35 AM, Gabe Black  wrote:

> Oh, also, the problem with EIO I think is not because there are EIO
> regressions, it's that the EIO code is being added in with EXTRAS and
> breaking the build for certain targets. Excluding it would be fairly
> trivial if I had write permission for the regression script on zizzer.
>
> Gabe
>
> On Tue, Apr 4, 2017 at 3:32 AM, Gabe Black  wrote:
>
>> Yeah, there are a lot of problems with the current system. It has three
>> real functions:
>>
>> 1. Making sure things run from end to end without crashing.
>> 2. Checking for inadvertent changes to the stats.
>> 3. Checking for non-determinstic behavior.
>>
>> Unfortunately it takes a really long time to run, doesn't distinguish
>> between trivial and non-trivial divergence in behavior, is really hard to
>> merge, doesn't tell you what's not working if something is broken, has
>> dependencies with major complications, isn't very useful when people
>> diverge from upstream, etc.
>>
>> I think there is definitely a role for that sort of test since those are
>> meaningful, but then there are lots and lots of potential testing that
>> we're not doing. We should have the few unit tests that already exist all
>> either pass or fail, not just output something, and then make them
>> easy/automatic to run, and we should have more of them. There are vast
>> swathes of functionality that really should be tested with unit tests like:
>>
>> 1. The CPU models.
>> 2. All the instructions for all the ISAs.
>> 3. All the Device models.
>> etc. etc.
>>
>> The amount of work it would/will take to cover the gap in testing is
>> enormous, but in my opinion that's the technical debt that has to be paid
>> down to straighten things out.
>>
>> Gabe
>>
>> On Tue, Apr 4, 2017 at 2:55 AM, Andreas Sandberg <
>> andreas.sandb...@arm.com> wrote:
>>
>>> On 01/04/2017 12:27, Gabe Black wrote:
>>>
 Hi folks. I'm working through the nightly regressions to get them to a
 good
 point for a rebase of our internal branch of gem5, and I've noticed a
 few
 things:

 1. The stats have been changed but not updated a bunch of times. I've
 identified almost all the points this has happened since the references
 were last updated, and have patches which fix them. Some stat changes
 are a
 little fishy, but I'll at least identify the guilty change(s) so that
 their
 authors can look them over.

>>>
>>> This is really hard to get right with the current system of "push to
>>> submit". I would really like to avoid including stat updates in normal
>>> code submissions. It would make it really hard to automatically submit
>>> code (there would be stat conflicts for every single non-trivial change)
>>> and it'd make cherry-picking really annoying.
>>>
>>> Ideally, the CI system should compare the stat output after applying a
>>> CL to the previous stat update. That way, you can easily spot the
>>> difference when submitting new code.
>>>
>>> 2. The SPARC FS regression were just plain not running because its
 configuration had been broken. I'll have a patch to fix this.
 3. The nightly regressions are still checking gem5 out from mercurial.

>>>
>>> We should obviously fix this. However, the repo is kept in sync with the
>>> golden git repo using a cron, so it's not quite as bad as it seems.
>>>
>>> 4. The "encumbered" repository has, as far as I can tell, not be
 converted
 from mercurial to git. Probably this isn't a problem because this code
 is
 mostly unchanging and becoming less relevant over time, especially since
 EIO support was removed from the process classes (it was, right?).
 5. The EIO code is also broken, because it tries to call "fatal" with a
 "(void)" cast in front of it in a ternary operation. Something like
 "foo ?
 (void)fatal("a bad thing happened") : (void)fatal("a different bad thing
 happened")". What "fatal" expands to now is apparently not compatible
 with
 this usage. Since I can access the encumbered repository, I can attempt
 to
 fix this.
 I can (and in at least in some cases will) fix most of these issues,
 except
 maybe 4 if we still want encumbered to exist. Please speak up if I've
 misinterpreted something or am missing some important bit of context.
 [1] https://www.mail-archive.com/gem5-dev@gem5.org/msg19438.html

>>>
>>> As far as I know, the encumbered/EIO repo has been deprecated. There was
>>> a discussion about deprecating old and broken ISAs a while back [1],
>>> that resulted in removing EIO as a way to reduce the test overhead.
>>> Steve sent out an email, which no one replied to, asking for EIO users
>>> [2] shortly after the discussion. I think he disabled EIO tests

[gem5-dev] Change in public/gem5[master]: stats: Update 04.gpu stats.

2017-04-04 Thread Gabe Black (Gerrit) 
Gabe Black has uploaded this change for review. (  
https://gem5-review.googlesource.com/2654



Change subject: stats: Update 04.gpu stats.
..

stats: Update 04.gpu stats.

A new stat was added by the CL:

commit b043dcf58ad766582aeab162fb855cc3fc95f2cf
Author: Andreas Sandberg 
Date:   Mon Feb 27 13:17:51 2017 +

gpu-compute: Fix Python/C++ object hierarchy discrepancies

Change-Id: I665a7eb0bea19f379c5fbaaf4686fcbe8c008159
---
M tests/quick/se/04.gpu/ref/x86/linux/gpu-ruby-GPU_RfO/config.ini
M tests/quick/se/04.gpu/ref/x86/linux/gpu-ruby-GPU_RfO/simerr
M tests/quick/se/04.gpu/ref/x86/linux/gpu-ruby-GPU_RfO/simout
M tests/quick/se/04.gpu/ref/x86/linux/gpu-ruby-GPU_RfO/stats.txt
4 files changed, 2,942 insertions(+), 2,942 deletions(-)




--
To view, visit https://gem5-review.googlesource.com/2654
To unsubscribe, visit https://gem5-review.googlesource.com/settings

Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-MessageType: newchange
Gerrit-Change-Id: I665a7eb0bea19f379c5fbaaf4686fcbe8c008159
Gerrit-Change-Number: 2654
Gerrit-PatchSet: 1
Gerrit-Owner: Gabe Black 
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: stats: Update the stats for 04.gpu for x86/linux/gpu-ruby-GP...

2017-04-04 Thread Gabe Black (Gerrit) 
Gabe Black has uploaded this change for review. (  
https://gem5-review.googlesource.com/2649



Change subject: stats: Update the stats for 04.gpu for  
x86/linux/gpu-ruby-GPU_Rf0.

..

stats: Update the stats for 04.gpu for x86/linux/gpu-ruby-GPU_Rf0.

These stats were changed by this CL:

commit a4b546c3a139aeb33f087422637ac06fc4477d11
Author: Matthew Poremba 
Date:   Thu Jan 19 11:58:59 2017 -0500

ruby: Add occupancy stats to MessageBuffers

Change-Id: I9713ed44d94cba424cdfa92d746dfe8007583b40
---
M tests/quick/se/04.gpu/ref/x86/linux/gpu-ruby-GPU_RfO/config.ini
M tests/quick/se/04.gpu/ref/x86/linux/gpu-ruby-GPU_RfO/simout
M tests/quick/se/04.gpu/ref/x86/linux/gpu-ruby-GPU_RfO/stats.txt
3 files changed, 164 insertions(+), 12 deletions(-)



diff --git  
a/tests/quick/se/04.gpu/ref/x86/linux/gpu-ruby-GPU_RfO/config.ini  
b/tests/quick/se/04.gpu/ref/x86/linux/gpu-ruby-GPU_RfO/config.ini

index 28bcdeb..2cb0689 100644
--- a/tests/quick/se/04.gpu/ref/x86/linux/gpu-ruby-GPU_RfO/config.ini
+++ b/tests/quick/se/04.gpu/ref/x86/linux/gpu-ruby-GPU_RfO/config.ini
@@ -420,7 +420,7 @@
 errout=cerr
 euid=100
 eventq_index=0
-executable=/dist/m5/regression/test-progs/gpu-hello/bin/x86/linux/gpu-hello
+executable=/usr/local/google/home/gabeblack/gem5/dist/m5/regression/test-progs/gpu-hello/bin/x86/linux/gpu-hello
 gid=100
 input=cin
 kvmInSE=false
@@ -1154,7 +1154,7 @@

 [system.cpu2.cl_driver]
 type=ClDriver
-codefile=/dist/m5/regression/test-progs/gpu-hello/bin/x86/linux/gpu-hello-kernel.asm
+codefile=/usr/local/google/home/gabeblack/gem5/dist/m5/regression/test-progs/gpu-hello/bin/x86/linux/gpu-hello-kernel.asm
 eventq_index=0
 filename=hsa

diff --git a/tests/quick/se/04.gpu/ref/x86/linux/gpu-ruby-GPU_RfO/simout  
b/tests/quick/se/04.gpu/ref/x86/linux/gpu-ruby-GPU_RfO/simout

index 6eab10f..23cce98 100755
--- a/tests/quick/se/04.gpu/ref/x86/linux/gpu-ruby-GPU_RfO/simout
+++ b/tests/quick/se/04.gpu/ref/x86/linux/gpu-ruby-GPU_RfO/simout
@@ -3,12 +3,12 @@
 gem5 Simulator System.  http://gem5.org
 gem5 is copyrighted software; use the --copyright option for details.

-gem5 compiled Nov 29 2016 19:21:01
-gem5 started Nov 29 2016 19:21:23
-gem5 executing on zizzer, pid 11568
-command line: /z/powerjg/gem5-upstream/build/HSAIL_X86/gem5.opt -d  
build/HSAIL_X86/tests/opt/quick/se/04.gpu/x86/linux/gpu-ruby-GPU_RfO -re  
/z/powerjg/gem5-upstream/tests/testing/../run.py  
quick/se/04.gpu/x86/linux/gpu-ruby-GPU_RfO

+gem5 compiled Mar 28 2017 14:30:03
+gem5 started Mar 28 2017 14:30:19
+gem5 executing on gabeblack-desktop.mtv.corp.google.com, pid 43422
+command line:  
/usr/local/google/home/gabeblack/gem5/gem5-public/build/HSAIL_X86/gem5.opt  
-d build/HSAIL_X86/tests/opt/quick/se/04.gpu/x86/linux/gpu-ruby-GPU_RfO -re  
/usr/local/google/home/gabeblack/gem5/gem5-public/tests/testing/../run.py  
quick/se/04.gpu/x86/linux/gpu-ruby-GPU_RfO


-Using GPU kernel code file(s)  
/dist/m5/regression/test-progs/gpu-hello/bin/x86/linux/gpu-hello-kernel.asm
+Using GPU kernel code file(s)  
/usr/local/google/home/gabeblack/gem5/dist/m5/regression/test-progs/gpu-hello/bin/x86/linux/gpu-hello-kernel.asm

 Global frequency set at 1 ticks per second
 Forcing maxCoalescedReqs to 32 (TLB assoc.)
 Forcing maxCoalescedReqs to 32 (TLB assoc.)
diff --git a/tests/quick/se/04.gpu/ref/x86/linux/gpu-ruby-GPU_RfO/stats.txt  
b/tests/quick/se/04.gpu/ref/x86/linux/gpu-ruby-GPU_RfO/stats.txt

index a879beb..f718d58 100644
--- a/tests/quick/se/04.gpu/ref/x86/linux/gpu-ruby-GPU_RfO/stats.txt
+++ b/tests/quick/se/04.gpu/ref/x86/linux/gpu-ruby-GPU_RfO/stats.txt
@@ -4,11 +4,11 @@
 sim_ticks
667407500   # Number of ticks simulated
 final_tick   
667407500   # Number of ticks from beginning of  
simulation (restored from checkpoints and never reset)
 sim_freq  
1   # Frequency of simulated ticks
-host_inst_rate   
72185   # Simulator instruction rate (inst/s)
-host_op_rate
148440   # Simulator op (including micro ops) rate  
(op/s)
-host_tick_rate   
719412350   # Simulator tick rate (ticks/s)
-host_mem_usage 
1308600   # Number of bytes of host memory used
-host_seconds  
0.93   # Real time elapsed on the host
+host_inst_rate  
176952   # Simulator instruction rate (inst/s)
+host_op_rate
363878   # Simulator op (including micro ops) rate  
(op/s)
+host_tick_rate  
1763538835

[gem5-dev] Change in public/gem5[master]: stats: Update some stats after simulated program exit behavi...

2017-04-04 Thread Gabe Black (Gerrit) 
Gabe Black has uploaded this change for review. (  
https://gem5-review.googlesource.com/2656



Change subject: stats: Update some stats after simulated program exit  
behavior was changed.

..

stats: Update some stats after simulated program exit behavior was changed.

The following CL delayed program exit and changed the stats for many if not
most of the SE mode regressions.

commit 2c1286865fc2542a0586ca4ff40b00765d17b348
Author: Brandon Potter 
Date:   Wed Mar 1 14:52:23 2017 -0600

syscall-emul: Rewrite system call exit code

Change-Id: Id241f2b7d5374947597c715ee44febe1acc5ea16
---
M tests/long/se/10.mcf/ref/arm/linux/o3-timing/config.ini
M tests/long/se/10.mcf/ref/arm/linux/o3-timing/simerr
M tests/long/se/10.mcf/ref/arm/linux/o3-timing/simout
M tests/long/se/10.mcf/ref/arm/linux/o3-timing/stats.txt
M tests/long/se/10.mcf/ref/sparc/linux/simple-timing/config.ini
M tests/long/se/10.mcf/ref/sparc/linux/simple-timing/simerr
M tests/long/se/10.mcf/ref/sparc/linux/simple-timing/simout
M tests/long/se/10.mcf/ref/sparc/linux/simple-timing/stats.txt
M tests/long/se/10.mcf/ref/x86/linux/o3-timing/config.ini
M tests/long/se/10.mcf/ref/x86/linux/o3-timing/simerr
M tests/long/se/10.mcf/ref/x86/linux/o3-timing/simout
M tests/long/se/10.mcf/ref/x86/linux/o3-timing/stats.txt
M tests/long/se/10.mcf/ref/x86/linux/simple-timing/config.ini
M tests/long/se/10.mcf/ref/x86/linux/simple-timing/simerr
M tests/long/se/10.mcf/ref/x86/linux/simple-timing/simout
M tests/long/se/10.mcf/ref/x86/linux/simple-timing/stats.txt
M tests/long/se/20.parser/ref/arm/linux/o3-timing/config.ini
M tests/long/se/20.parser/ref/arm/linux/o3-timing/simerr
M tests/long/se/20.parser/ref/arm/linux/o3-timing/simout
M tests/long/se/20.parser/ref/arm/linux/o3-timing/stats.txt
M tests/long/se/20.parser/ref/arm/linux/simple-atomic/config.ini
M tests/long/se/20.parser/ref/arm/linux/simple-atomic/simerr
M tests/long/se/20.parser/ref/arm/linux/simple-atomic/simout
M tests/long/se/20.parser/ref/arm/linux/simple-atomic/stats.txt
M tests/long/se/20.parser/ref/arm/linux/simple-timing/config.ini
M tests/long/se/20.parser/ref/arm/linux/simple-timing/simerr
M tests/long/se/20.parser/ref/arm/linux/simple-timing/simout
M tests/long/se/20.parser/ref/arm/linux/simple-timing/stats.txt
M tests/long/se/20.parser/ref/x86/linux/o3-timing/config.ini
M tests/long/se/20.parser/ref/x86/linux/o3-timing/simerr
M tests/long/se/20.parser/ref/x86/linux/o3-timing/simout
M tests/long/se/20.parser/ref/x86/linux/o3-timing/stats.txt
M tests/long/se/20.parser/ref/x86/linux/simple-atomic/config.ini
M tests/long/se/20.parser/ref/x86/linux/simple-atomic/simerr
M tests/long/se/20.parser/ref/x86/linux/simple-atomic/simout
M tests/long/se/20.parser/ref/x86/linux/simple-atomic/stats.txt
M tests/long/se/20.parser/ref/x86/linux/simple-timing/config.ini
M tests/long/se/20.parser/ref/x86/linux/simple-timing/simerr
M tests/long/se/20.parser/ref/x86/linux/simple-timing/simout
M tests/long/se/20.parser/ref/x86/linux/simple-timing/stats.txt
M tests/long/se/30.eon/ref/arm/linux/o3-timing/config.ini
M tests/long/se/30.eon/ref/arm/linux/o3-timing/simerr
M tests/long/se/30.eon/ref/arm/linux/o3-timing/simout
M tests/long/se/30.eon/ref/arm/linux/o3-timing/stats.txt
M tests/long/se/30.eon/ref/arm/linux/simple-atomic/config.ini
M tests/long/se/30.eon/ref/arm/linux/simple-atomic/simerr
M tests/long/se/30.eon/ref/arm/linux/simple-atomic/simout
M tests/long/se/30.eon/ref/arm/linux/simple-atomic/stats.txt
M tests/long/se/30.eon/ref/arm/linux/simple-timing/config.ini
M tests/long/se/30.eon/ref/arm/linux/simple-timing/simerr
M tests/long/se/30.eon/ref/arm/linux/simple-timing/simout
M tests/long/se/30.eon/ref/arm/linux/simple-timing/stats.txt
M tests/long/se/40.perlbmk/ref/arm/linux/o3-timing/config.ini
M tests/long/se/40.perlbmk/ref/arm/linux/o3-timing/simout
M tests/long/se/40.perlbmk/ref/arm/linux/o3-timing/stats.txt
M tests/long/se/40.perlbmk/ref/arm/linux/simple-atomic/config.ini
M tests/long/se/40.perlbmk/ref/arm/linux/simple-atomic/simerr
M tests/long/se/40.perlbmk/ref/arm/linux/simple-atomic/simout
M tests/long/se/40.perlbmk/ref/arm/linux/simple-atomic/stats.txt
M tests/long/se/40.perlbmk/ref/arm/linux/simple-timing/config.ini
M tests/long/se/40.perlbmk/ref/arm/linux/simple-timing/simerr
M tests/long/se/40.perlbmk/ref/arm/linux/simple-timing/simout
M tests/long/se/40.perlbmk/ref/arm/linux/simple-timing/stats.txt
M tests/long/se/50.vortex/ref/arm/linux/o3-timing/config.ini
M tests/long/se/50.vortex/ref/arm/linux/o3-timing/simerr
M tests/long/se/50.vortex/ref/arm/linux/o3-timing/simout
M tests/long/se/50.vortex/ref/arm/linux/o3-timing/stats.txt
M tests/long/se/60.bzip2/ref/arm/linux/o3-timing/config.ini
M tests/long/se/60.bzip2/ref/arm/linux/o3-timing/simerr
M tests/long/se/60.bzip2/ref/arm/linux/o3-timing/simout
M tests/long/se/60.bzip2/ref/arm/linux/o3-timing/stats.txt
M

[gem5-dev] Change in public/gem5[master]: stats: Update the 40.m5threads stats.

2017-04-04 Thread Gabe Black (Gerrit) 
Gabe Black has uploaded this change for review. (  
https://gem5-review.googlesource.com/2652



Change subject: stats: Update the 40.m5threads stats.
..

stats: Update the 40.m5threads stats.

The change below changed the stats for the o3 version of the 40.m5threads
regression.

commit 2367198921765848a4f5b3d020a7cc5776209f80
Author: Brandon Potter 
Date:   Mon Feb 27 14:10:15 2017 -0500

syscall_emul: [PATCH 15/22] add clone/execve for threading and
multiprocess simulations

Change-Id: I601c58d8d1453cf93f2065ea5816b63b553610e0
---
M  
tests/quick/se/40.m5threads-test-atomic/ref/sparc/linux/o3-timing-mp/config.ini
M  
tests/quick/se/40.m5threads-test-atomic/ref/sparc/linux/o3-timing-mp/simerr
M  
tests/quick/se/40.m5threads-test-atomic/ref/sparc/linux/o3-timing-mp/simout
M  
tests/quick/se/40.m5threads-test-atomic/ref/sparc/linux/o3-timing-mp/stats.txt

4 files changed, 2,988 insertions(+), 2,980 deletions(-)




--
To view, visit https://gem5-review.googlesource.com/2652
To unsubscribe, visit https://gem5-review.googlesource.com/settings

Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-MessageType: newchange
Gerrit-Change-Id: I601c58d8d1453cf93f2065ea5816b63b553610e0
Gerrit-Change-Number: 2652
Gerrit-PatchSet: 1
Gerrit-Owner: Gabe Black 
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: stats: Update the solaris boot stats for the new op classes.

2017-04-04 Thread Gabe Black (Gerrit) 
Gabe Black has uploaded this change for review. (  
https://gem5-review.googlesource.com/2648



Change subject: stats: Update the solaris boot stats for the new op classes.
..

stats: Update the solaris boot stats for the new op classes.

The change below introduced some new op classes which have their own stats,
and the counts the instructions used to be under have gone down.

commit 6c72c3551978ef2eabbe9727bf24fd2fcf385318
Author: Fernando Endo 
Date:   Sat Oct 15 14:58:45 2016 -0500

cpu, arm: Distinguish Float* and SimdFloat*, create FloatMem*  
opClass


Change-Id: Ifa3a279493f503585a7b2cbb2785b106e24184bb
---
M  
tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.ini
M  
tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.json

M tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/simout
M  
tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/stats.txt

4 files changed, 47 insertions(+), 31 deletions(-)



diff --git  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.ini  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.ini

index e473f5b..ed41ed4 100644
---  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.ini
+++  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.ini

@@ -28,7 +28,7 @@
 load_addr_mask=1099511627775
 load_offset=0
 mem_mode=atomic
-mem_ranges=1048576:68157439 2147483648:2415919103
+mem_ranges=1048576:68157439:0:0:0:0 2147483648:2415919103:0:0:0:0
 memories=system.hypervisor_desc system.nvram system.partition_desc  
system.physmem0 system.physmem1 system.rom

 mmap_using_noreserve=false
 multi_thread=false
@@ -71,7 +71,7 @@
 p_state_clk_gate_max=20
 p_state_clk_gate_min=2
 power_model=Null
-ranges=133412421632:133412421639 134217728000:554050781183  
644245094400:652835028991 725849473024:1095485095935  
1099255955456:1099255955463
+ranges=133412421632:133412421639:0:0:0:0 134217728000:554050781183:0:0:0:0  
644245094400:652835028991:0:0:0:0 725849473024:1095485095935:0:0:0:0  
1099255955456:1099255955463:0:0:0:0

 req_size=16
 resp_size=16
 master=system.iobus.slave[0]
@@ -204,6 +204,7 @@
 default_p_state=UNDEFINED
 eventq_index=0
 in_addr_map=true
+kvm_map=true
 latency=60
 latency_var=0
 null=false
@@ -211,7 +212,7 @@
 p_state_clk_gate_max=20
 p_state_clk_gate_min=2
 power_model=Null
-range=133446500352:133446508543
+range=133446500352:133446508543:0:0:0:0
 port=system.membus.master[5]

 [system.intrctrl]
@@ -297,6 +298,7 @@
 default_p_state=UNDEFINED
 eventq_index=0
 in_addr_map=true
+kvm_map=true
 latency=60
 latency_var=0
 null=false
@@ -304,7 +306,7 @@
 p_state_clk_gate_max=20
 p_state_clk_gate_min=2
 power_model=Null
-range=133429198848:133429207039
+range=133429198848:133429207039:0:0:0:0
 port=system.membus.master[4]

 [system.partition_desc]
@@ -315,6 +317,7 @@
 default_p_state=UNDEFINED
 eventq_index=0
 in_addr_map=true
+kvm_map=true
 latency=60
 latency_var=0
 null=false
@@ -322,7 +325,7 @@
 p_state_clk_gate_max=20
 p_state_clk_gate_min=2
 power_model=Null
-range=133445976064:133445984255
+range=133445976064:133445984255:0:0:0:0
 port=system.membus.master[6]

 [system.physmem0]
@@ -333,6 +336,7 @@
 default_p_state=UNDEFINED
 eventq_index=0
 in_addr_map=true
+kvm_map=true
 latency=60
 latency_var=0
 null=false
@@ -340,7 +344,7 @@
 p_state_clk_gate_max=20
 p_state_clk_gate_min=2
 power_model=Null
-range=1048576:68157439
+range=1048576:68157439:0:0:0:0
 port=system.membus.master[7]

 [system.physmem1]
@@ -351,6 +355,7 @@
 default_p_state=UNDEFINED
 eventq_index=0
 in_addr_map=true
+kvm_map=true
 latency=60
 latency_var=0
 null=false
@@ -358,7 +363,7 @@
 p_state_clk_gate_max=20
 p_state_clk_gate_min=2
 power_model=Null
-range=2147483648:2415919103
+range=2147483648:2415919103:0:0:0:0
 port=system.membus.master[8]

 [system.rom]
@@ -369,6 +374,7 @@
 default_p_state=UNDEFINED
 eventq_index=0
 in_addr_map=true
+kvm_map=true
 latency=60
 latency_var=0
 null=false
@@ -376,7 +382,7 @@
 p_state_clk_gate_max=20
 p_state_clk_gate_min=2
 power_model=Null
-range=1099243192320:1099251580927
+range=1099243192320:1099251580927:0:0:0:0
 port=system.membus.master[3]

 [system.t1000]
diff --git  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.json  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.json

index 940cdb0..913ebaa 100644
---  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.json
+++  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.json

@@ -6,13 +6,14 @@
 "mmap_using_noreserve": false,
 "kernel_addr_check": true,
 "rom": {
-"range": "1099243192320:1099251580927",
+

[gem5-dev] Change in public/gem5[master]: config: Add a default system disk image for SPARC FS.

2017-04-04 Thread Gabe Black (Gerrit) 
Gabe Black has uploaded this change for review. (  
https://gem5-review.googlesource.com/2645



Change subject: config: Add a default system disk image for SPARC FS.
..

config: Add a default system disk image for SPARC FS.

When the change below removed the hard coded disk name for the SPARC FS
configuration, it broke the regression which had not specified a disk name.
This change adds a default disk name so that the regression will continue to
work like it used to, but preserving the effect of this other change.

commit 86a25bbcee88f6e69299867b6264885d738f636e
Author: Jakub Jermar 
Date:   Tue Jul 19 09:52:46 2016 -0500

config: Allow SPARC FS image to be specified on the command line

Change-Id: Ieb317b2bf573a4f2fc435d34cccd1f246c28d84c
---
M configs/common/Benchmarks.py
1 file changed, 2 insertions(+), 0 deletions(-)



diff --git a/configs/common/Benchmarks.py b/configs/common/Benchmarks.py
index bf0a2ad..dec1e3e 100644
--- a/configs/common/Benchmarks.py
+++ b/configs/common/Benchmarks.py
@@ -60,6 +60,8 @@
 return env.get('LINUX_IMAGE', disk('x86root.img'))
 elif buildEnv['TARGET_ISA'] == 'arm':
 return env.get('LINUX_IMAGE', disk('linux-aarch32-ael.img'))
+elif buildEnv['TARGET_ISA'] == 'sparc':
+return env.get('LINUX_IMAGE', disk('disk.s10hw2'))
 else:
 print "Don't know what default disk image to use for %s ISA" %  
\

 buildEnv['TARGET_ISA']

--
To view, visit https://gem5-review.googlesource.com/2645
To unsubscribe, visit https://gem5-review.googlesource.com/settings

Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-MessageType: newchange
Gerrit-Change-Id: Ieb317b2bf573a4f2fc435d34cccd1f246c28d84c
Gerrit-Change-Number: 2645
Gerrit-PatchSet: 1
Gerrit-Owner: Gabe Black 
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: stats: Update ARM FS stats.

2017-04-04 Thread Gabe Black (Gerrit) 
Gabe Black has uploaded this change for review. (  
https://gem5-review.googlesource.com/2653



Change subject: stats: Update ARM FS stats.
..

stats: Update ARM FS stats.

The change below changed the behavior of interrupts on ARM and changed the
stats for the 10.linux-boot regression.

commit 746e2f3c27ad83c36b7bc3b8bd3c92004fcf995b
Author: Sudhanshu Jha 
Date:   Mon Feb 27 10:29:56 2017 +

arm, kmi: Clear interrupts in KMI devices

Change-Id: Ie1cfc26777f6ed2d3fd4340175941fda1fdb5b6a
---
M tests/long/fs/10.linux-boot/ref/arm/linux/realview-minor-dual/config.ini
M tests/long/fs/10.linux-boot/ref/arm/linux/realview-minor-dual/simerr
M tests/long/fs/10.linux-boot/ref/arm/linux/realview-minor-dual/simout
M tests/long/fs/10.linux-boot/ref/arm/linux/realview-minor-dual/stats.txt
M tests/long/fs/10.linux-boot/ref/arm/linux/realview-minor/config.ini
M tests/long/fs/10.linux-boot/ref/arm/linux/realview-minor/simerr
M tests/long/fs/10.linux-boot/ref/arm/linux/realview-minor/simout
M tests/long/fs/10.linux-boot/ref/arm/linux/realview-minor/stats.txt
M tests/long/fs/10.linux-boot/ref/arm/linux/realview-o3-dual/config.ini
M tests/long/fs/10.linux-boot/ref/arm/linux/realview-o3-dual/simerr
M tests/long/fs/10.linux-boot/ref/arm/linux/realview-o3-dual/simout
M tests/long/fs/10.linux-boot/ref/arm/linux/realview-o3-dual/stats.txt
M tests/long/fs/10.linux-boot/ref/arm/linux/realview-o3-dual/system.terminal
M tests/long/fs/10.linux-boot/ref/arm/linux/realview-o3/config.ini
M tests/long/fs/10.linux-boot/ref/arm/linux/realview-o3/simerr
M tests/long/fs/10.linux-boot/ref/arm/linux/realview-o3/simout
M tests/long/fs/10.linux-boot/ref/arm/linux/realview-o3/stats.txt
M  
tests/quick/fs/10.linux-boot/ref/arm/linux/realview-simple-timing-dual/config.ini
M  
tests/quick/fs/10.linux-boot/ref/arm/linux/realview-simple-timing-dual/simerr
M  
tests/quick/fs/10.linux-boot/ref/arm/linux/realview-simple-timing-dual/simout
M  
tests/quick/fs/10.linux-boot/ref/arm/linux/realview-simple-timing-dual/stats.txt
M  
tests/quick/fs/10.linux-boot/ref/arm/linux/realview-simple-timing/config.ini

M tests/quick/fs/10.linux-boot/ref/arm/linux/realview-simple-timing/simerr
M tests/quick/fs/10.linux-boot/ref/arm/linux/realview-simple-timing/simout
M  
tests/quick/fs/10.linux-boot/ref/arm/linux/realview-simple-timing/stats.txt

25 files changed, 15,657 insertions(+), 15,490 deletions(-)




--
To view, visit https://gem5-review.googlesource.com/2653
To unsubscribe, visit https://gem5-review.googlesource.com/settings

Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-MessageType: newchange
Gerrit-Change-Id: Ie1cfc26777f6ed2d3fd4340175941fda1fdb5b6a
Gerrit-Change-Number: 2653
Gerrit-PatchSet: 1
Gerrit-Owner: Gabe Black 
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: stats: Update SPARC solaris boot stats.

2017-04-04 Thread Gabe Black (Gerrit) 
Gabe Black has uploaded this change for review. (  
https://gem5-review.googlesource.com/2644



Change subject: stats: Update SPARC solaris boot stats.
..

stats: Update SPARC solaris boot stats.

The CPU power state bins where changed by the following
CL:

commit fb5fc11da49938660ea22c336964677cdba890e1
Author: David Guillen Fandos 
Date:   Mon Jun 6 17:16:43 2016 +0100

pwr: Low-power idle power state for idle CPUs

Change-Id: I8b3924681c8a85b7bbe061b671faf274ce882f91
---
M tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/simerr
M tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/simout
M  
tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/stats.txt

3 files changed, 9 insertions(+), 8 deletions(-)



diff --git  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/simerr  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/simerr

index 2807da6..7e4b384 100755
---  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/simerr
+++  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/simerr

@@ -36,4 +36,5 @@
 0.145519 rounded to 0
 warn: Sockets disabled, not accepting terminal connections
 warn: Sockets disabled, not accepting gdb connections
+warn: ClockedObject: More than one power state change request encountered  
within the same simulation tick

 warn: Don't know what interrupt to clear for console.
diff --git  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/simout  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/simout

index 1b486a6..a8b9bd2 100755
---  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/simout
+++  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/simout

@@ -3,9 +3,9 @@
 gem5 Simulator System.  http://gem5.org
 gem5 is copyrighted software; use the --copyright option for details.

-gem5 compiled Apr  4 2017 01:06:08
-gem5 started Apr  4 2017 01:06:18
-gem5 executing on gabeblack-desktop.mtv.corp.google.com, pid 98195
+gem5 compiled Apr  4 2017 01:51:46
+gem5 started Apr  4 2017 01:51:57
+gem5 executing on gabeblack-desktop.mtv.corp.google.com, pid 121003
 command line:  
/usr/local/google/home/gabeblack/gem5/gem5-public/build/SPARC/gem5.opt -d  
build/SPARC/tests/opt/long/fs/80.solaris-boot/sparc/solaris/t1000-simple-atomic  
-re  
/usr/local/google/home/gabeblack/gem5/gem5-public/tests/testing/../run.py  
long/fs/80.solaris-boot/sparc/solaris/t1000-simple-atomic


 Global frequency set at 20 ticks per second
diff --git  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/stats.txt  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/stats.txt

index a382e7a..9861ba8 100644
---  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/stats.txt
+++  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/stats.txt

@@ -4,11 +4,11 @@
 sim_ticks   
4467555024   # Number of ticks simulated
 final_tick  
4467555024   # Number of ticks from beginning of  
simulation (restored from checkpoints and never reset)
 sim_freq
20   # Frequency of simulated ticks
-host_inst_rate 
323   # Simulator instruction rate (inst/s)
-host_op_rate   
3290176   # Simulator op (including micro ops) rate  
(op/s)
-host_tick_rate 
6593981   # Simulator tick rate (ticks/s)
+host_inst_rate 
3232456   # Simulator instruction rate (inst/s)
+host_op_rate   
3233727   # Simulator op (including micro ops) rate  
(op/s)
+host_tick_rate 
6480848   # Simulator tick rate (ticks/s)
 host_mem_usage  
550344   # Number of bytes of host memory used
-host_seconds
677.52   # Real time elapsed on the host
+host_seconds
689.35   # Real time elapsed on the host
 sim_insts   
2228284650   # Number of instructions simulated
 sim_ops 
2229160714   # Number of ops (including micro ops)  
simulated
 system.voltage_domain.voltage
1   # Voltage in Volts

@@ -116,7 +116,7 @@
 system.pwrStateResidencyTicks::UNDEFINED
4467555024

[gem5-dev] Change in public/gem5[master]: stats: Update the solaris boot stats for the default snoop_f...

2017-04-04 Thread Gabe Black (Gerrit) 
Gabe Black has uploaded this change for review. (  
https://gem5-review.googlesource.com/2647



Change subject: stats: Update the solaris boot stats for the default  
snoop_filter.

..

stats: Update the solaris boot stats for the default snoop_filter.

The snoop_filter was enabled by default by this change:

commit 080d4e08d627b5b726afec71d38370373b7376c5
Author: Andreas Hansson 
Date:   Fri Aug 12 14:11:45 2016 +0100

mem: Add snoop filter to SystemXBar by default

Change-Id: I850473c70437588b47812f1dc00d6ecdb66daa36
---
M  
tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.ini
M  
tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.json

M tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/simout
M  
tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/stats.txt

4 files changed, 38 insertions(+), 16 deletions(-)



diff --git  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.ini  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.ini

index fa3a6c4..e473f5b 100644
---  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.ini
+++  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.ini

@@ -238,7 +238,7 @@

 [system.membus]
 type=CoherentXBar
-children=badaddr_responder
+children=badaddr_responder snoop_filter
 clk_domain=system.clk_domain
 default_p_state=UNDEFINED
 eventq_index=0
@@ -250,7 +250,7 @@
 point_of_coherency=true
 power_model=Null
 response_latency=2
-snoop_filter=Null
+snoop_filter=system.membus.snoop_filter
 snoop_response_latency=4
 system=system
 use_default_range=false
@@ -282,6 +282,13 @@
 warn_access=
 pio=system.membus.default

+[system.membus.snoop_filter]
+type=SnoopFilter
+eventq_index=0
+lookup_latency=1
+max_capacity=8388608
+system=system
+
 [system.nvram]
 type=SimpleMemory
 bandwidth=0.00
diff --git  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.json  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.json

index d3a1b4f..940cdb0 100644
---  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.json
+++  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.json

@@ -721,7 +721,16 @@
 "role": "SLAVE"
 },
 "p_state_clk_gate_min": 2,
-"snoop_filter": null,
+"snoop_filter": {
+"name": "snoop_filter",
+"system": "system",
+"max_capacity": 8388608,
+"eventq_index": 0,
+"cxx_class": "SnoopFilter",
+"path": "system.membus.snoop_filter",
+"type": "SnoopFilter",
+"lookup_latency": 1
+},
 "power_model": null,
 "path": "system.membus",
 "snoop_response_latency": 4,
diff --git  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/simout  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/simout

index 3247e07..8347db8 100755
---  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/simout
+++  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/simout

@@ -3,9 +3,9 @@
 gem5 Simulator System.  http://gem5.org
 gem5 is copyrighted software; use the --copyright option for details.

-gem5 compiled Apr  4 2017 02:11:37
-gem5 started Apr  4 2017 02:11:47
-gem5 executing on gabeblack-desktop.mtv.corp.google.com, pid 135111
+gem5 compiled Apr  4 2017 02:30:37
+gem5 started Apr  4 2017 02:30:47
+gem5 executing on gabeblack-desktop.mtv.corp.google.com, pid 2108
 command line:  
/usr/local/google/home/gabeblack/gem5/gem5-public/build/SPARC/gem5.opt -d  
build/SPARC/tests/opt/long/fs/80.solaris-boot/sparc/solaris/t1000-simple-atomic  
-re  
/usr/local/google/home/gabeblack/gem5/gem5-public/tests/testing/../run.py  
long/fs/80.solaris-boot/sparc/solaris/t1000-simple-atomic


 Global frequency set at 20 ticks per second
diff --git  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/stats.txt  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/stats.txt

index 3106af3..e3f3402 100644
---  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/stats.txt
+++  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/stats.txt

@@ -4,11 +4,11 @@
 sim_ticks   
4467555024   # Number of ticks simulated
 final_tick  
4467555024   # Number of ticks from beginning of  
simulation (restored from checkpoints and never reset)
 sim_freq
20   # Frequency of

[gem5-dev] Change in public/gem5[master]: stats: Update 01.hello-2T-smt and 40.perlbmks stats on ARM/A...

2017-04-04 Thread Gabe Black (Gerrit) 
Gabe Black has uploaded this change for review. (  
https://gem5-review.googlesource.com/2650



Change subject: stats: Update 01.hello-2T-smt and 40.perlbmks stats on  
ARM/Alpha o3-timing.

..

stats: Update 01.hello-2T-smt and 40.perlbmks stats on ARM/Alpha o3-timing.

The following change removed a write to an integer register when completing
a system call. This changed the reference statistics slightly.

commit 073cb266079edddec64ea8cd5169dd2cbef8f812
Author: Brandon Potter 
Date:   Mon Feb 27 14:10:02 2017 -0500

syscall_emul: [patch 14/22] adds identifier system calls

Change-Id: I3bee42ab826dd9cbc49aab34340da57caf4f045d
---
M tests/long/se/40.perlbmk/ref/arm/linux/o3-timing/config.ini
M tests/long/se/40.perlbmk/ref/arm/linux/o3-timing/simerr
M tests/long/se/40.perlbmk/ref/arm/linux/o3-timing/simout
M tests/long/se/40.perlbmk/ref/arm/linux/o3-timing/stats.txt
M tests/quick/se/01.hello-2T-smt/ref/alpha/linux/o3-timing-mt/config.ini
M tests/quick/se/01.hello-2T-smt/ref/alpha/linux/o3-timing-mt/simerr
M tests/quick/se/01.hello-2T-smt/ref/alpha/linux/o3-timing-mt/simout
M tests/quick/se/01.hello-2T-smt/ref/alpha/linux/o3-timing-mt/stats.txt
8 files changed, 2,545 insertions(+), 2,504 deletions(-)




--
To view, visit https://gem5-review.googlesource.com/2650
To unsubscribe, visit https://gem5-review.googlesource.com/settings

Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-MessageType: newchange
Gerrit-Change-Id: I3bee42ab826dd9cbc49aab34340da57caf4f045d
Gerrit-Change-Number: 2650
Gerrit-PatchSet: 1
Gerrit-Owner: Gabe Black 
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: stats: Update the solaris boot stats for new snoopTraffic stat.

2017-04-04 Thread Gabe Black (Gerrit) 
Gabe Black has uploaded this change for review. (  
https://gem5-review.googlesource.com/2646



Change subject: stats: Update the solaris boot stats for new snoopTraffic  
stat.

..

stats: Update the solaris boot stats for new snoopTraffic stat.

The following change added the new stat:

commit 0020662459fdd9efcfe9864ef12160515434ccdb
Author: David Guillen Fandos 
Date:   Thu Jul 21 17:19:14 2016 +0100

mem: Add snoop traffic statistic

Change-Id: I9ee0fb4b8cc97c6b94e76ab5524f89c78c97d1a6
---
M  
tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.ini
M  
tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.json

M tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/simout
M  
tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/stats.txt

4 files changed, 67 insertions(+), 8 deletions(-)



diff --git  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.ini  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.ini

index 8fe2ef1..fa3a6c4 100644
---  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.ini
+++  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/config.ini

@@ -44,6 +44,7 @@
 partition_desc=system.partition_desc
 partition_desc_addr=133445976064
  
partition_desc_bin=/usr/local/google/home/gabeblack/gem5/dist/m5/system/binaries/1up-md.bin

+power_model=Null
  
readfile=/usr/local/google/home/gabeblack/gem5/gem5-public/tests/testing/../halt.sh

 reset_addr=1099243192320
  
reset_bin=/usr/local/google/home/gabeblack/gem5/dist/m5/system/binaries/reset_new.bin

@@ -69,6 +70,7 @@
 p_state_clk_gate_bins=20
 p_state_clk_gate_max=20
 p_state_clk_gate_min=2
+power_model=Null
 ranges=133412421632:133412421639 134217728000:554050781183  
644245094400:652835028991 725849473024:1095485095935  
1099255955456:1099255955463

 req_size=16
 resp_size=16
@@ -110,6 +112,7 @@
 p_state_clk_gate_bins=20
 p_state_clk_gate_max=20
 p_state_clk_gate_min=2
+power_model=Null
 profile=0
 progress_interval=0
 simpoint_start_insts=
@@ -166,6 +169,7 @@
 p_state_clk_gate_min=2
 pio_addr=134217728000
 pio_latency=200
+power_model=Null
 system=system
 pio=system.iobus.master[14]

@@ -206,6 +210,7 @@
 p_state_clk_gate_bins=20
 p_state_clk_gate_max=20
 p_state_clk_gate_min=2
+power_model=Null
 range=133446500352:133446508543
 port=system.membus.master[5]

@@ -224,6 +229,7 @@
 p_state_clk_gate_bins=20
 p_state_clk_gate_max=20
 p_state_clk_gate_min=2
+power_model=Null
 response_latency=2
 use_default_range=false
 width=16
@@ -242,6 +248,7 @@
 p_state_clk_gate_max=20
 p_state_clk_gate_min=2
 point_of_coherency=true
+power_model=Null
 response_latency=2
 snoop_filter=Null
 snoop_response_latency=4
@@ -264,6 +271,7 @@
 pio_addr=0
 pio_latency=200
 pio_size=8
+power_model=Null
 ret_bad_addr=true
 ret_data16=65535
 ret_data32=4294967295
@@ -288,6 +296,7 @@
 p_state_clk_gate_bins=20
 p_state_clk_gate_max=20
 p_state_clk_gate_min=2
+power_model=Null
 range=133429198848:133429207039
 port=system.membus.master[4]

@@ -305,6 +314,7 @@
 p_state_clk_gate_bins=20
 p_state_clk_gate_max=20
 p_state_clk_gate_min=2
+power_model=Null
 range=133445976064:133445984255
 port=system.membus.master[6]

@@ -322,6 +332,7 @@
 p_state_clk_gate_bins=20
 p_state_clk_gate_max=20
 p_state_clk_gate_min=2
+power_model=Null
 range=1048576:68157439
 port=system.membus.master[7]

@@ -339,6 +350,7 @@
 p_state_clk_gate_bins=20
 p_state_clk_gate_max=20
 p_state_clk_gate_min=2
+power_model=Null
 range=2147483648:2415919103
 port=system.membus.master[8]

@@ -356,6 +368,7 @@
 p_state_clk_gate_bins=20
 p_state_clk_gate_max=20
 p_state_clk_gate_min=2
+power_model=Null
 range=1099243192320:1099251580927
 port=system.membus.master[3]

@@ -378,6 +391,7 @@
 pio_addr=644245094400
 pio_latency=200
 pio_size=4294967296
+power_model=Null
 ret_bad_addr=false
 ret_data16=65535
 ret_data32=4294967295
@@ -400,6 +414,7 @@
 pio_addr=549755813888
 pio_latency=200
 pio_size=4294967296
+power_model=Null
 ret_bad_addr=false
 ret_data16=65535
 ret_data32=4294967295
@@ -422,6 +437,7 @@
 pio_addr=725849473024
 pio_latency=200
 pio_size=8
+power_model=Null
 ret_bad_addr=false
 ret_data16=65535
 ret_data32=4294967295
@@ -444,6 +460,7 @@
 pio_addr=725849473088
 pio_latency=200
 pio_size=8
+power_model=Null
 ret_bad_addr=false
 ret_data16=65535
 ret_data32=4294967295
@@ -466,6 +483,7 @@
 pio_addr=725849473152
 pio_latency=200
 pio_size=8
+power_model=Null
 ret_bad_addr=false
 ret_data16=65535
 ret_data32=4294967295
@@ -488,6 +506,7 @@
 pio_addr=725849473216
 pio_latency=200
 pio_size=8
+power_model=Null
 ret_bad_addr=false
 ret_data16=65535
 ret_data32=4294967295
@@ -510,6 +529,7 @@
 pio_addr=734439407616
 pio_latency=200
 pio_size=8

[gem5-dev] Change in public/gem5[master]: stats: Update the stats for 70.twolf for x86 o3-timing mode.

2017-04-04 Thread Gabe Black (Gerrit) 
Gabe Black has uploaded this change for review. (  
https://gem5-review.googlesource.com/2655



Change subject: stats: Update the stats for 70.twolf for x86 o3-timing mode.
..

stats: Update the stats for 70.twolf for x86 o3-timing mode.

The following CL changed the stats:

commit 43418e7f81099072fb7d56dae0ae1d858162
Author: Brandon Potter 
Date:   Wed Mar 1 13:07:43 2017 -0600

syscall-emul: Move memState into its own file

It would be a good idea to try to figure out why, since it doesn't *look*  
like

this change was intended to move things around in memory or otherwise change
simulated behavior.

Change-Id: I0173ffdfb680a91b8c91f2bf5d7f72c76e7a8b63
---
M tests/long/se/70.twolf/ref/x86/linux/o3-timing/config.ini
M tests/long/se/70.twolf/ref/x86/linux/o3-timing/simerr
M tests/long/se/70.twolf/ref/x86/linux/o3-timing/simout
M tests/long/se/70.twolf/ref/x86/linux/o3-timing/stats.txt
4 files changed, 1,126 insertions(+), 10,848 deletions(-)




--
To view, visit https://gem5-review.googlesource.com/2655
To unsubscribe, visit https://gem5-review.googlesource.com/settings

Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-MessageType: newchange
Gerrit-Change-Id: I0173ffdfb680a91b8c91f2bf5d7f72c76e7a8b63
Gerrit-Change-Number: 2655
Gerrit-PatchSet: 1
Gerrit-Owner: Gabe Black 
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: stats: Un-empty the SPARC FS stats.txt file.

2017-04-04 Thread Gabe Black (Gerrit) 
Gabe Black has uploaded this change for review. (  
https://gem5-review.googlesource.com/2641



Change subject: stats: Un-empty the SPARC FS stats.txt file.
..

stats: Un-empty the SPARC FS stats.txt file.

This was emptied accidentally by the CL below. A lot of other files were  
too,

but those were eventually refilled.

commit 62b6ff22ec1f90014b1d0fc778014bdb38cc09ce
Author: Curtis Dunham 
Date:   Tue May 31 11:07:18 2016 +0100

stats: update for snoop filter tweak

Change-Id: I34aefca51a92a6a98f6a8fdbdab7106cc1fff171
---
M  
tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/stats.txt

1 file changed, 251 insertions(+), 0 deletions(-)



diff --git  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/stats.txt  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/stats.txt

index e69de29..e3be24d 100644
---  
a/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/stats.txt
+++  
b/tests/long/fs/80.solaris-boot/ref/sparc/solaris/t1000-simple-atomic/stats.txt

@@ -0,0 +1,251 @@
+
+-- Begin Simulation Statistics --
+sim_seconds   
2.233778   # Number of seconds simulated
+sim_ticks   
4467555024   # Number of ticks simulated
+final_tick  
4467555024   # Number of ticks from beginning of  
simulation (restored from checkpoints and never reset)
+sim_freq
20   # Frequency of simulated ticks
+host_inst_rate 
1658224   # Simulator instruction rate (inst/s)
+host_op_rate   
1658876   # Simulator op (including micro ops) rate  
(op/s)
+host_tick_rate 
3324623   # Simulator tick rate (ticks/s)
+host_mem_usage  
518260   # Number of bytes of host memory used
+host_seconds   
1343.78   # Real time elapsed on the host
+sim_insts   
2228284650   # Number of instructions simulated
+sim_ops 
2229160714   # Number of ops (including micro ops)  
simulated
+system.voltage_domain.voltage
1   # Voltage in Volts
+system.clk_domain.clock  
2   # Clock period in ticks
+system.hypervisor_desc.bytes_read::cpu.data 
16792   # Number of bytes read from this memory
+system.hypervisor_desc.bytes_read::total 
16792   # Number of bytes read from this memory
+system.hypervisor_desc.num_reads::cpu.data  
9024   # Number of read requests responded to by this  
memory
+system.hypervisor_desc.num_reads::total   
9024   # Number of read requests responded to by this  
memory
+system.hypervisor_desc.bw_read::cpu.data  
7517   # Total read bandwidth from this memory (bytes/s)
+system.hypervisor_desc.bw_read::total 
7517   # Total read bandwidth from this memory (bytes/s)
+system.hypervisor_desc.bw_total::cpu.data  
7517   # Total bandwidth to/from this memory (bytes/s)
+system.hypervisor_desc.bw_total::total
7517   # Total bandwidth to/from this memory (bytes/s)
+system.nvram.bytes_read::cpu.data  
284   # Number of bytes read from this memory
+system.nvram.bytes_read::total 
284   # Number of bytes read from this memory
+system.nvram.bytes_written::cpu.data
92   # Number of bytes written to this memory
+system.nvram.bytes_written::total   
92   # Number of bytes written to this memory
+system.nvram.num_reads::cpu.data   
284   # Number of read requests responded to by this  
memory
+system.nvram.num_reads::total  
284   # Number of read requests responded to by this  
memory
+system.nvram.num_writes::cpu.data   
92   # Number of write requests responded to by this  
memory
+system.nvram.num_writes::total  
92   # Number of write requests responded to by this  
memory
+system.nvram.bw_read::cpu.data 
127   # Total read bandwidth from this memory (bytes/s)
+system.nvram.bw_read::total
127

Re: [gem5-dev] adding reviewers in gerrit?

2017-04-04 Thread Paul Rosenfeld (prosenfeld) 
Hi Jason, 

I don't know if you had a chance to look into this, but I just uploaded my 
first patch to gerrit and I also seem to be missing the ability to add 
reviewers. When I type someone into the reviewers box there is no auto complete 
and when I add someone manually and click OK, the reviewer field is still 
blank. 

Regards, 
Paul

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Jason Lowe-Power
Sent: Saturday, March 25, 2017 11:38 AM
To: gem5 Developer List 
Subject: Re: [gem5-dev] adding reviewers in gerrit?

Hi Gabe,

Hmm... It works for me. It's possible that we don't have the permissions set up 
correctly to allow anyone to add reviewers. I just tested with a non-admin 
account and it doesn't work for that account either. I'll look into it.

Cheers,
Jason

On Sat, Mar 25, 2017 at 5:32 AM Gabe Black  wrote:

> Hi folks. I've uploaded a few CLs to gerrit now, and I notice that I 
> can't add reviewers since it claims everyone I try to add isn't a 
> registered user. That's very odd, because I'm trying to add people who 
> have given me review feedback on earlier changes, and people who I can 
> look up activity for on gerrit. Does anybody know why it's not 
> behaving for me? My other CL got reviewed so it's not a problem yet, 
> but it would be nice if I could direct my CLs to the appropriate people 
> instead of hoping they see them.
>
> Gabe
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: arm, sim: fix context switch stats dumps for ARM64/Linux

2017-04-04 Thread Paul Rosenfeld (Gerrit) 
Paul Rosenfeld has uploaded this change for review. (  
https://gem5-review.googlesource.com/2640



Change subject: arm,sim: fix context switch stats dumps for ARM64/Linux
..

arm,sim: fix context switch stats dumps for ARM64/Linux

32bit and 64bit Linux have different arguments passed to the
__switch_to() function that gem5 hooks into in order to collect context
switch statistics. 64bit Linux provides the task_struct pointer to the
next task that will be switched to, which means we don't have to look
up the task_struct from thread_info as we do in 32bit ARM Linux.

This patch adds a second set of accessors to ThreadInfo to extract
details such as the pid, tgid, task name, etc., directly from a
task_struct. The existing accessors maintain their existing behavior by
first looking up the task_struct and then calling these new accessors.

A 64-bit variant of the DumpStatsPCEvent class is added that uses these
new accessors to get the task details for the context switch dumps
directly from the task_struct passed to __switch_to().

Change-Id: I63c4b3e1ad64446751a91f6340901d5180d7382d
---
M src/arch/arm/linux/system.cc
M src/arch/arm/linux/system.hh
M src/arch/generic/linux/threadinfo.hh
3 files changed, 116 insertions(+), 24 deletions(-)



diff --git a/src/arch/arm/linux/system.cc b/src/arch/arm/linux/system.cc
index 52e075d..7f06475 100644
--- a/src/arch/arm/linux/system.cc
+++ b/src/arch/arm/linux/system.cc
@@ -236,7 +236,14 @@
 LinuxArmSystem::startup()
 {
 if (enableContextSwitchStatsDump) {
-dumpStatsPCEvent =  
addKernelFuncEvent("__switch_to");

+if (!highestELIs64()) {
+dumpStatsPCEvent =
+addKernelFuncEvent("__switch_to");
+} else {
+dumpStatsPCEvent =
+addKernelFuncEvent("__switch_to");
+}
+
 if (!dumpStatsPCEvent)
panic("dumpStatsPCEvent not created!");

@@ -276,25 +283,64 @@
 Linux::dumpDmesg(getThreadContext(0), std::cout);
 }

-/** This function is called whenever the the kernel function
- *  "__switch_to" is called to change running tasks.
+/**
+ * Extracts the information used by the DumpStatsPCEvent by reading the
+ * thread_info pointer passed to __switch_to() in 32 bit ARM Linux
  *
  *  r0 = task_struct of the previously running process
- *  r1 = task_info of the previously running process
- *  r2 = task_info of the next process to run
+ *  r1 = thread_info of the previously running process
+ *  r2 = thread_info of the next process to run
+ */
+void
+DumpStatsPCEvent::getTaskDetails(ThreadContext *tc, uint32_t ,
+uint32_t , std::string _task_str, int32_t ) {
+
+Linux::ThreadInfo ti(tc);
+Addr task_descriptor = tc->readIntReg(2);
+pid = ti.curTaskPID(task_descriptor);
+tgid = ti.curTaskTGID(task_descriptor);
+next_task_str = ti.curTaskName(task_descriptor);
+
+// Streamline treats pid == -1 as the kernel process.
+// Also pid == 0 implies idle process (except during Linux boot)
+mm = ti.curTaskMm(task_descriptor);
+}
+
+/**
+ * Extracts the information used by the DumpStatsPCEvent64 by reading the
+ * task_struct pointer passed to __switch_to() in 64 bit ARM Linux
+ *
+ *  r0 = task_struct of the previously running process
+ *  r1 = task_struct of next process to run
+ */
+void
+DumpStatsPCEvent64::getTaskDetails(ThreadContext *tc, uint32_t ,
+uint32_t , std::string _task_str, int32_t ) {
+
+Linux::ThreadInfo ti(tc);
+Addr task_struct = tc->readIntReg(1);
+pid = ti.curTaskPIDFromTaskStruct(task_struct);
+tgid = ti.curTaskTGIDFromTaskStruct(task_struct);
+next_task_str = ti.curTaskNameFromTaskStruct(task_struct);
+
+// Streamline treats pid == -1 as the kernel process.
+// Also pid == 0 implies idle process (except during Linux boot)
+mm = ti.curTaskMmFromTaskStruct(task_struct);
+}
+
+/** This function is called whenever the the kernel function
+ *  "__switch_to" is called to change running tasks.
  */
 void
 DumpStatsPCEvent::process(ThreadContext *tc)
 {
-Linux::ThreadInfo ti(tc);
-Addr task_descriptor = tc->readIntReg(2);
-uint32_t pid = ti.curTaskPID(task_descriptor);
-uint32_t tgid = ti.curTaskTGID(task_descriptor);
-std::string next_task_str = ti.curTaskName(task_descriptor);
+uint32_t pid = 0;
+uint32_t tgid = 0;
+std::string next_task_str;
+int32_t mm = 0;

-// Streamline treats pid == -1 as the kernel process.
-// Also pid == 0 implies idle process (except during Linux boot)
-int32_t mm = ti.curTaskMm(task_descriptor);
+getTaskDetails(tc, pid, tgid, next_task_str, mm);
+
 bool is_kernel = (mm == 0);
 if (is_kernel && (pid != 0)) {
 pid = -1;
diff --git a/src/arch/arm/linux/system.hh b/src/arch/arm/linux/system.hh
index 709776f..247ebae 100644
--- a/src/arch/arm/linux/system.hh
+++ b/src/arch/arm/linux/system.hh
@@ -132,6 +132,20 @@
 {}

 virtual void

Re: [gem5-dev] nightly regressions

2017-04-04 Thread Gabe Black 
Oh, also, the problem with EIO I think is not because there are EIO
regressions, it's that the EIO code is being added in with EXTRAS and
breaking the build for certain targets. Excluding it would be fairly
trivial if I had write permission for the regression script on zizzer.

Gabe

On Tue, Apr 4, 2017 at 3:32 AM, Gabe Black  wrote:

> Yeah, there are a lot of problems with the current system. It has three
> real functions:
>
> 1. Making sure things run from end to end without crashing.
> 2. Checking for inadvertent changes to the stats.
> 3. Checking for non-determinstic behavior.
>
> Unfortunately it takes a really long time to run, doesn't distinguish
> between trivial and non-trivial divergence in behavior, is really hard to
> merge, doesn't tell you what's not working if something is broken, has
> dependencies with major complications, isn't very useful when people
> diverge from upstream, etc.
>
> I think there is definitely a role for that sort of test since those are
> meaningful, but then there are lots and lots of potential testing that
> we're not doing. We should have the few unit tests that already exist all
> either pass or fail, not just output something, and then make them
> easy/automatic to run, and we should have more of them. There are vast
> swathes of functionality that really should be tested with unit tests like:
>
> 1. The CPU models.
> 2. All the instructions for all the ISAs.
> 3. All the Device models.
> etc. etc.
>
> The amount of work it would/will take to cover the gap in testing is
> enormous, but in my opinion that's the technical debt that has to be paid
> down to straighten things out.
>
> Gabe
>
> On Tue, Apr 4, 2017 at 2:55 AM, Andreas Sandberg  > wrote:
>
>> On 01/04/2017 12:27, Gabe Black wrote:
>>
>>> Hi folks. I'm working through the nightly regressions to get them to a
>>> good
>>> point for a rebase of our internal branch of gem5, and I've noticed a few
>>> things:
>>>
>>> 1. The stats have been changed but not updated a bunch of times. I've
>>> identified almost all the points this has happened since the references
>>> were last updated, and have patches which fix them. Some stat changes
>>> are a
>>> little fishy, but I'll at least identify the guilty change(s) so that
>>> their
>>> authors can look them over.
>>>
>>
>> This is really hard to get right with the current system of "push to
>> submit". I would really like to avoid including stat updates in normal
>> code submissions. It would make it really hard to automatically submit
>> code (there would be stat conflicts for every single non-trivial change)
>> and it'd make cherry-picking really annoying.
>>
>> Ideally, the CI system should compare the stat output after applying a
>> CL to the previous stat update. That way, you can easily spot the
>> difference when submitting new code.
>>
>> 2. The SPARC FS regression were just plain not running because its
>>> configuration had been broken. I'll have a patch to fix this.
>>> 3. The nightly regressions are still checking gem5 out from mercurial.
>>>
>>
>> We should obviously fix this. However, the repo is kept in sync with the
>> golden git repo using a cron, so it's not quite as bad as it seems.
>>
>> 4. The "encumbered" repository has, as far as I can tell, not be converted
>>> from mercurial to git. Probably this isn't a problem because this code is
>>> mostly unchanging and becoming less relevant over time, especially since
>>> EIO support was removed from the process classes (it was, right?).
>>> 5. The EIO code is also broken, because it tries to call "fatal" with a
>>> "(void)" cast in front of it in a ternary operation. Something like "foo
>>> ?
>>> (void)fatal("a bad thing happened") : (void)fatal("a different bad thing
>>> happened")". What "fatal" expands to now is apparently not compatible
>>> with
>>> this usage. Since I can access the encumbered repository, I can attempt
>>> to
>>> fix this.
>>> I can (and in at least in some cases will) fix most of these issues,
>>> except
>>> maybe 4 if we still want encumbered to exist. Please speak up if I've
>>> misinterpreted something or am missing some important bit of context.
>>> [1] https://www.mail-archive.com/gem5-dev@gem5.org/msg19438.html
>>>
>>
>> As far as I know, the encumbered/EIO repo has been deprecated. There was
>> a discussion about deprecating old and broken ISAs a while back [1],
>> that resulted in removing EIO as a way to reduce the test overhead.
>> Steve sent out an email, which no one replied to, asking for EIO users
>> [2] shortly after the discussion. I think he disabled EIO tests after
>> that.
>>
>> We should probably think about what fixing means in this case. I have
>> actively removed stat diffing from tests that I consider to be
>> functional (e.g., atomic boot, CPU switching, checkpointing).
>>
>> I wouldn't mind disabling stat diffing altogether until we have figured
>> out what to do for performance regressions. I'd

Re: [gem5-dev] nightly regressions

2017-04-04 Thread Gabe Black 
Yeah, there are a lot of problems with the current system. It has three
real functions:

1. Making sure things run from end to end without crashing.
2. Checking for inadvertent changes to the stats.
3. Checking for non-determinstic behavior.

Unfortunately it takes a really long time to run, doesn't distinguish
between trivial and non-trivial divergence in behavior, is really hard to
merge, doesn't tell you what's not working if something is broken, has
dependencies with major complications, isn't very useful when people
diverge from upstream, etc.

I think there is definitely a role for that sort of test since those are
meaningful, but then there are lots and lots of potential testing that
we're not doing. We should have the few unit tests that already exist all
either pass or fail, not just output something, and then make them
easy/automatic to run, and we should have more of them. There are vast
swathes of functionality that really should be tested with unit tests like:

1. The CPU models.
2. All the instructions for all the ISAs.
3. All the Device models.
etc. etc.

The amount of work it would/will take to cover the gap in testing is
enormous, but in my opinion that's the technical debt that has to be paid
down to straighten things out.

Gabe

On Tue, Apr 4, 2017 at 2:55 AM, Andreas Sandberg 
wrote:

> On 01/04/2017 12:27, Gabe Black wrote:
>
>> Hi folks. I'm working through the nightly regressions to get them to a
>> good
>> point for a rebase of our internal branch of gem5, and I've noticed a few
>> things:
>>
>> 1. The stats have been changed but not updated a bunch of times. I've
>> identified almost all the points this has happened since the references
>> were last updated, and have patches which fix them. Some stat changes are
>> a
>> little fishy, but I'll at least identify the guilty change(s) so that
>> their
>> authors can look them over.
>>
>
> This is really hard to get right with the current system of "push to
> submit". I would really like to avoid including stat updates in normal
> code submissions. It would make it really hard to automatically submit
> code (there would be stat conflicts for every single non-trivial change)
> and it'd make cherry-picking really annoying.
>
> Ideally, the CI system should compare the stat output after applying a
> CL to the previous stat update. That way, you can easily spot the
> difference when submitting new code.
>
> 2. The SPARC FS regression were just plain not running because its
>> configuration had been broken. I'll have a patch to fix this.
>> 3. The nightly regressions are still checking gem5 out from mercurial.
>>
>
> We should obviously fix this. However, the repo is kept in sync with the
> golden git repo using a cron, so it's not quite as bad as it seems.
>
> 4. The "encumbered" repository has, as far as I can tell, not be converted
>> from mercurial to git. Probably this isn't a problem because this code is
>> mostly unchanging and becoming less relevant over time, especially since
>> EIO support was removed from the process classes (it was, right?).
>> 5. The EIO code is also broken, because it tries to call "fatal" with a
>> "(void)" cast in front of it in a ternary operation. Something like "foo ?
>> (void)fatal("a bad thing happened") : (void)fatal("a different bad thing
>> happened")". What "fatal" expands to now is apparently not compatible with
>> this usage. Since I can access the encumbered repository, I can attempt to
>> fix this.
>> I can (and in at least in some cases will) fix most of these issues,
>> except
>> maybe 4 if we still want encumbered to exist. Please speak up if I've
>> misinterpreted something or am missing some important bit of context.
>> [1] https://www.mail-archive.com/gem5-dev@gem5.org/msg19438.html
>>
>
> As far as I know, the encumbered/EIO repo has been deprecated. There was
> a discussion about deprecating old and broken ISAs a while back [1],
> that resulted in removing EIO as a way to reduce the test overhead.
> Steve sent out an email, which no one replied to, asking for EIO users
> [2] shortly after the discussion. I think he disabled EIO tests after that.
>
> We should probably think about what fixing means in this case. I have
> actively removed stat diffing from tests that I consider to be
> functional (e.g., atomic boot, CPU switching, checkpointing).
>
> I wouldn't mind disabling stat diffing altogether until we have figured
> out what to do for performance regressions. I'd prefer to see some more
> directed performance tests that target specific components (e.g., using
> traces) and specific stats.
>
> //Andreas
>
> [2] https://www.mail-archive.com/gem5-dev@gem5.org/msg19379.html
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the

Re: [gem5-dev] nightly regressions

2017-04-04 Thread Andreas Sandberg 

On 01/04/2017 12:27, Gabe Black wrote:

Hi folks. I'm working through the nightly regressions to get them to a good
point for a rebase of our internal branch of gem5, and I've noticed a few
things:

1. The stats have been changed but not updated a bunch of times. I've
identified almost all the points this has happened since the references
were last updated, and have patches which fix them. Some stat changes are a
little fishy, but I'll at least identify the guilty change(s) so that their
authors can look them over.


This is really hard to get right with the current system of "push to
submit". I would really like to avoid including stat updates in normal
code submissions. It would make it really hard to automatically submit
code (there would be stat conflicts for every single non-trivial change)
and it'd make cherry-picking really annoying.

Ideally, the CI system should compare the stat output after applying a
CL to the previous stat update. That way, you can easily spot the
difference when submitting new code.


2. The SPARC FS regression were just plain not running because its
configuration had been broken. I'll have a patch to fix this.
3. The nightly regressions are still checking gem5 out from mercurial.


We should obviously fix this. However, the repo is kept in sync with the
golden git repo using a cron, so it's not quite as bad as it seems.


4. The "encumbered" repository has, as far as I can tell, not be converted
from mercurial to git. Probably this isn't a problem because this code is
mostly unchanging and becoming less relevant over time, especially since
EIO support was removed from the process classes (it was, right?).
5. The EIO code is also broken, because it tries to call "fatal" with a
"(void)" cast in front of it in a ternary operation. Something like "foo ?
(void)fatal("a bad thing happened") : (void)fatal("a different bad thing
happened")". What "fatal" expands to now is apparently not compatible with
this usage. Since I can access the encumbered repository, I can attempt to
fix this.
I can (and in at least in some cases will) fix most of these issues, except
maybe 4 if we still want encumbered to exist. Please speak up if I've
misinterpreted something or am missing some important bit of context.
[1] https://www.mail-archive.com/gem5-dev@gem5.org/msg19438.html


As far as I know, the encumbered/EIO repo has been deprecated. There was
a discussion about deprecating old and broken ISAs a while back [1],
that resulted in removing EIO as a way to reduce the test overhead.
Steve sent out an email, which no one replied to, asking for EIO users
[2] shortly after the discussion. I think he disabled EIO tests after that.

We should probably think about what fixing means in this case. I have
actively removed stat diffing from tests that I consider to be
functional (e.g., atomic boot, CPU switching, checkpointing).

I wouldn't mind disabling stat diffing altogether until we have figured
out what to do for performance regressions. I'd prefer to see some more
directed performance tests that target specific components (e.g., using
traces) and specific stats.

//Andreas

[2] https://www.mail-archive.com/gem5-dev@gem5.org/msg19379.html
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Cron <m5test@zizzer> /z/m5/regression/do-regression quick

2017-04-04 Thread Cron Daemon 
*** diff[simerr]: SKIPPED* 
build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby: CHANGED!
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing: 
CHANGED!* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-simple:
 CHANGED!
* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-two-level:
 CHANGED!
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-atomic: CHANGED!
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing: CHANGED!
* build/POWER/tests/opt/quick/se/00.hello/power/linux/simple-atomic: 
CHANGED!
* build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing: CHANGED!
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-atomic: 
CHANGED!
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/simple-timing: 
CHANGED!
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing-ruby: 
CHANGED!
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/o3-timing: CHANGED!
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/simple-atomic: 
CHANGED!
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing: 
CHANGED!
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp:
 CHANGED!
* 
build/SPARC/tests/opt/quick/se/03.learning-gem5/sparc/linux/learning-gem5-p1-simple:
 CHANGED!
* 
build/SPARC/tests/opt/quick/se/03.learning-gem5/sparc/linux/learning-gem5-p1-two-level:
 CHANGED!
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-timing-mp:
 CHANGED!
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/o3-timing-mp:
 CHANGED!
* build/SPARC/tests/opt/quick/se/50.vortex/sparc/linux/simple-atomic: 
CHANGED!
* build/SPARC/tests/opt/quick/se/70.twolf/sparc/linux/simple-atomic: 
CHANGED!
* build/SPARC/tests/opt/quick/se/50.vortex/sparc/linux/simple-timing: 
CHANGED!
* build/SPARC/tests/opt/quick/se/10.mcf/sparc/linux/simple-atomic: CHANGED!
* build/SPARC/tests/opt/quick/se/70.twolf/sparc/linux/simple-timing: 
CHANGED!
* 
build/X86/tests/opt/quick/se/03.learning-gem5/x86/linux/learning-gem5-p1-simple:
 CHANGED!
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing: CHANGED!
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing-ruby: 
CHANGED!Maximum error magnitude: +100.00%
* 
build/X86/tests/opt/quick/se/03.learning-gem5/x86/linux/learning-gem5-p1-two-level:
 CHANGED!
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-atomic: CHANGED!
* build/X86/tests/opt/quick/se/00.hello/x86/linux/o3-timing: CHANGED!
* build/X86/tests/opt/quick/se/70.twolf/x86/linux/simple-atomic: CHANGED!
* build/X86/tests/opt/quick/se/10.mcf/x86/linux/simple-atomic: CHANGED!
* build/X86/tests/opt/quick/se/70.twolf/x86/linux/simple-timing: CHANGED!
* build/ARM/tests/opt/quick/se/50.vortex/arm/linux/simple-atomic: CHANGED!
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/simple-timing: CHANGED!
* build/ARM/tests/opt/quick/se/10.mcf/arm/linux/simple-timing: CHANGED!
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/o3-timing-checker: 
CHANGED!
* 
build/ARM/tests/opt/quick/se/03.learning-gem5/arm/linux/learning-gem5-p1-two-level:
 CHANGED!
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/o3-timing: CHANGED!
* 
build/ARM/tests/opt/quick/se/03.learning-gem5/arm/linux/learning-gem5-p1-simple:
 CHANGED!
* build/ARM/tests/opt/quick/se/50.vortex/arm/linux/simple-timing: CHANGED!
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/simple-atomic: CHANGED!
* 
build/ARM/tests/opt/quick/se/00.hello/arm/linux/simple-atomic-dummychecker: 
CHANGED!
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/minor-timing: CHANGED!
* 
build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-timing: 
CHANGED!
* 
build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-timing-dual:
 CHANGED!
* build/ARM/tests/opt/quick/se/10.mcf/arm/linux/simple-atomic: CHANGED!
* build/ARM/tests/opt/quick/se/70.twolf/arm/linux/simple-atomic: CHANGED!
* build/ARM/tests/opt/quick/se/70.twolf/arm/linux/simple-timing: CHANGED!
* build/RISCV/tests/opt/quick/se/00.hello/riscv/linux/simple-atomic: 
CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64a/simple-timing: 
CHANGED!
* build/RISCV/tests/opt/quick/se/00.hello/riscv/linux/simple-timing: 
CHANGED!
* build/RISCV/tests/opt/quick/se/00.hello/riscv/linux/simple-timing-ruby: 
CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64a/simple-timing-ruby:
 CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64a/simple-atomic: 
CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64m/simple-timing-ruby:
 CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64d/simple-atomic: 
CHANGED!