Discussion:
[gem5-dev] Regression changes due to last push (d0934b57735a)
(too old to reply)
Andreas Hansson
2015-08-27 12:19:23 UTC
Permalink
Hi Joel,

It seems the patch from Emilio changes a few of the full system regressions. I merely wanted to check if you simply forgot to push a stats update?

In general I would expect anyone pushing patches to do a full regression run (and sanity check any changes). Agreed?

Thanks,

Andreas


-- 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.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Joel Hestness
2015-08-27 13:34:30 UTC
Permalink
Hi Andreas,
Yes, I agree that committers should run full regressions (i.e. all quick
tests that are verified daily on Zizzer, right?). I ran quick regressions
that are configured correctly, and they pass with this patch.

The problem with running all quick regressions currently is that many
tests don't run out-of-the-box, and I haven't found instructions on how to
set up tests like the cpu2000 and FS tests. I made a request for such
information in this thread, though I haven't yet seen response:
https://www.mail-archive.com/gem5-***@gem5.org/msg16328.html

I'm totally willing to run all the quick regressions and update as
appropriate, but I'd like more information on these. How does one set up FS
and cpu2000 tests? Can we include Linux binaries in the tests/ directory so
those tests can run out-of-the-box? Can we change the cpu2000 tests to some
other benchmarks without distribution restrictions, so they too can be
included in tests/?

Thanks,
Joel
Post by Andreas Hansson
Hi Joel,
It seems the patch from Emilio changes a few of the full system
regressions. I merely wanted to check if you simply forgot to push a stats
update?
In general I would expect anyone pushing patches to do a full regression
run (and sanity check any changes). Agreed?
Thanks,
Andreas
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
Andreas Hansson
2015-08-27 16:46:18 UTC
Permalink
Hi Joel,

A full regression run covers all ISAs and tests, not just quick. This is
around 50-60 host CPU hours.

On zizzer you should be able to run it without any issues. For systems
other than zizzer, the FS regressions need the FS files from the download
section on the wiki. As you point out, the cpu2000 tests rely on binaries
we cannot distribute :-(.

When it comes to the point of using tests that we can distribute, that
would be great, but that is a whole different discussion imho. Feel free
to start that thread with a proposal. The LLVM test suite might be one
option...

Andreas


On 27/08/2015 14:34, "gem5-dev on behalf of Joel Hestness"
Post by Joel Hestness
Hi Andreas,
Yes, I agree that committers should run full regressions (i.e. all quick
tests that are verified daily on Zizzer, right?). I ran quick regressions
that are configured correctly, and they pass with this patch.
The problem with running all quick regressions currently is that many
tests don't run out-of-the-box, and I haven't found instructions on how to
set up tests like the cpu2000 and FS tests. I made a request for such
I'm totally willing to run all the quick regressions and update as
appropriate, but I'd like more information on these. How does one set up FS
and cpu2000 tests? Can we include Linux binaries in the tests/ directory so
those tests can run out-of-the-box? Can we change the cpu2000 tests to some
other benchmarks without distribution restrictions, so they too can be
included in tests/?
Thanks,
Joel
Post by Andreas Hansson
Hi Joel,
It seems the patch from Emilio changes a few of the full system
regressions. I merely wanted to check if you simply forgot to push a stats
update?
In general I would expect anyone pushing patches to do a full regression
run (and sanity check any changes). Agreed?
Thanks,
Andreas
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- 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.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Joel Hestness
2015-08-27 19:10:17 UTC
Permalink
Post by Andreas Hansson
On zizzer you should be able to run it without any issues. For systems
other than zizzer, the FS regressions need the FS files from the download
section on the wiki. As you point out, the cpu2000 tests rely on binaries
we cannot distribute :-(.
I see. A big part of my misunderstanding then is that I've never had access
to Zizzer, though I've had gem5 commit access since 2011. Is there a
process in place for getting access to Zizzer and running regressions there?
Post by Andreas Hansson
A full regression run covers all ISAs and tests, not just quick. This is
around 50-60 host CPU hours.
Hm, I was not aware that this was the community's plan. This seems pretty
unclear to me. For instance, the gem5 submission wiki page (
http://gem5.org/Submitting_Contributions) lacks precise information about
which tests must be working and updated, and only states that quick tests
must be run. It doesn't include anything about updating the regressions,
which ones, or when the updates need to take place.

Assuming all committers are on the same page about what constitutes "full
regressions", I'll volunteer to update the page to clarify that the
committer is responsible for updating all regressions as appropriate when a
change is committed. Do we want to set a specific timeline for this (e.g.
within the same set of changesets that change regressions, or within the
next X days)?


Can I also suggest a couple things?:
1) It is also currently unclear which tests are required based on the
daily cron regressions emails, and especially since the do-regression
script isn't available in gem5. At a minimum, we should update scons or
do-regression on Zizzer to print all regression test names daily. Another
good thing to do is to include do-regression in gem5, so all contributors
can see how regressions are run. If we decide not to run full regressions
daily, those that are not run (but need to be as part of a "full
regression") should be marked with something more descriptive than
"skipped" like the currently tracing regressions (eio, tgen).

2) ::Expanding on my prior email:: If we formalize "full regressions" to
include all tests, then we *really* need to include full, out-of-the-box
runable regressions within the gem5 repo or at least using nicely packaged
binaries/disks in a tar file (NOTE: even the FS files tarball requires
modifying configs/common/SysPaths.py so the simulator can find the files).
It should be possible for both committers AND patch contributors to run the
full regression suite (not just those committers with access to Zizzer).
Otherwise, it seems like an unreasonable expectation for committers with
access to Zizzer to completely manage regression test updates.

Probably also makes sense to firm up and document committer/Zizzer access
and regression plans while I go through as a partial guinea pig.

Joel



On 27/08/2015 14:34, "gem5-dev on behalf of Joel Hestness"
Post by Andreas Hansson
Post by Joel Hestness
Hi Andreas,
Yes, I agree that committers should run full regressions (i.e. all quick
tests that are verified daily on Zizzer, right?). I ran quick regressions
that are configured correctly, and they pass with this patch.
The problem with running all quick regressions currently is that many
tests don't run out-of-the-box, and I haven't found instructions on how to
set up tests like the cpu2000 and FS tests. I made a request for such
I'm totally willing to run all the quick regressions and update as
appropriate, but I'd like more information on these. How does one set up FS
and cpu2000 tests? Can we include Linux binaries in the tests/ directory so
those tests can run out-of-the-box? Can we change the cpu2000 tests to some
other benchmarks without distribution restrictions, so they too can be
included in tests/?
Thanks,
Joel
Post by Andreas Hansson
Hi Joel,
It seems the patch from Emilio changes a few of the full system
regressions. I merely wanted to check if you simply forgot to push a stats
update?
In general I would expect anyone pushing patches to do a full regression
run (and sanity check any changes). Agreed?
Thanks,
Andreas
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
Andreas Hansson
2015-08-27 21:12:05 UTC
Permalink
Hi Joel,

I always run util/regress with ‘all'. This will build all ISAs and run all
tests. You shouldn’t need anything else imho.

Preferably make sure you have protobuf so that the tgen tests are run as
well. Eio I agree we should probably nuke, although that’s a separate
discussion.

I would suggest the stats update should always be pushed at the same time
as the change that would otherwise break the regressions. Anytime someone
does a pull all regressions should pass. As simple as that.

The challenge with distributing test binaries is licenses, and sheer size.
I agree it would be good to have something openly available, and have
precompiled binaries in a separate repository or a tarball. Any
suggestions are welcome. Until we have something to replace the current
ones we need to stick to what we have...

For the FS ones you don’t have to modify anything, just set M5_PATH.

Andreas


On 27/08/2015 20:10, "gem5-dev on behalf of Joel Hestness"
Post by Joel Hestness
Post by Andreas Hansson
On zizzer you should be able to run it without any issues. For systems
other than zizzer, the FS regressions need the FS files from the download
section on the wiki. As you point out, the cpu2000 tests rely on binaries
we cannot distribute :-(.
I see. A big part of my misunderstanding then is that I've never had access
to Zizzer, though I've had gem5 commit access since 2011. Is there a
process in place for getting access to Zizzer and running regressions there?
Post by Andreas Hansson
A full regression run covers all ISAs and tests, not just quick. This is
around 50-60 host CPU hours.
Hm, I was not aware that this was the community's plan. This seems pretty
unclear to me. For instance, the gem5 submission wiki page (
http://gem5.org/Submitting_Contributions) lacks precise information about
which tests must be working and updated, and only states that quick tests
must be run. It doesn't include anything about updating the regressions,
which ones, or when the updates need to take place.
Assuming all committers are on the same page about what constitutes "full
regressions", I'll volunteer to update the page to clarify that the
committer is responsible for updating all regressions as appropriate when a
change is committed. Do we want to set a specific timeline for this (e.g.
within the same set of changesets that change regressions, or within the
next X days)?
1) It is also currently unclear which tests are required based on the
daily cron regressions emails, and especially since the do-regression
script isn't available in gem5. At a minimum, we should update scons or
do-regression on Zizzer to print all regression test names daily. Another
good thing to do is to include do-regression in gem5, so all contributors
can see how regressions are run. If we decide not to run full regressions
daily, those that are not run (but need to be as part of a "full
regression") should be marked with something more descriptive than
"skipped" like the currently tracing regressions (eio, tgen).
2) ::Expanding on my prior email:: If we formalize "full regressions" to
include all tests, then we *really* need to include full, out-of-the-box
runable regressions within the gem5 repo or at least using nicely packaged
binaries/disks in a tar file (NOTE: even the FS files tarball requires
modifying configs/common/SysPaths.py so the simulator can find the files).
It should be possible for both committers AND patch contributors to run the
full regression suite (not just those committers with access to Zizzer).
Otherwise, it seems like an unreasonable expectation for committers with
access to Zizzer to completely manage regression test updates.
Probably also makes sense to firm up and document committer/Zizzer access
and regression plans while I go through as a partial guinea pig.
Joel
On 27/08/2015 14:34, "gem5-dev on behalf of Joel Hestness"
Post by Andreas Hansson
Post by Joel Hestness
Hi Andreas,
Yes, I agree that committers should run full regressions (i.e. all
quick
Post by Joel Hestness
tests that are verified daily on Zizzer, right?). I ran quick
regressions
Post by Joel Hestness
that are configured correctly, and they pass with this patch.
The problem with running all quick regressions currently is that many
tests don't run out-of-the-box, and I haven't found instructions on
how to
Post by Joel Hestness
set up tests like the cpu2000 and FS tests. I made a request for such
I'm totally willing to run all the quick regressions and update as
appropriate, but I'd like more information on these. How does one set
up
Post by Joel Hestness
FS
and cpu2000 tests? Can we include Linux binaries in the tests/
directory
Post by Joel Hestness
so
those tests can run out-of-the-box? Can we change the cpu2000 tests to some
other benchmarks without distribution restrictions, so they too can be
included in tests/?
Thanks,
Joel
On Thu, Aug 27, 2015 at 7:19 AM, Andreas Hansson
Post by Andreas Hansson
Hi Joel,
It seems the patch from Emilio changes a few of the full system
regressions. I merely wanted to check if you simply forgot to push a stats
update?
In general I would expect anyone pushing patches to do a full
regression
Post by Joel Hestness
Post by Andreas Hansson
run (and sanity check any changes). Agreed?
Thanks,
Andreas
-- IMPORTANT NOTICE: The contents of this email and any attachments
are
Post by Joel Hestness
Post by Andreas Hansson
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose
the
Post by Joel Hestness
Post by Andreas Hansson
contents to any other person, use it for any purpose, or store or
copy
Post by Joel Hestness
Post by Andreas Hansson
the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- 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.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Andreas Hansson
2015-08-28 07:27:38 UTC
Permalink
More problems in paradise.

It turns out, on a full regression run, that the particular changeset
causes a massive increase in the run-time (30%) and instruction count for
build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview64-o3 and
build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview64-o3-checker.
I suspect some interrupt/quiesce oddity, or even bug. Note that these are
already some of our longest running regressions (3+ hours), and this
change just added 1 hour to each of them.

I am not sure what to suggest. The run-time increase is troublesome, the
fact that such a small change suddenly adds 30% to the instruction count
of a single-core regression is even more alarming. Joel, any ideas? Anyone
else?

Andreas

On 27/08/2015 22:12, "gem5-dev on behalf of Andreas Hansson"
Post by Andreas Hansson
Hi Joel,
I always run util/regress with ‘all'. This will build all ISAs and run all
tests. You shouldn’t need anything else imho.
Preferably make sure you have protobuf so that the tgen tests are run as
well. Eio I agree we should probably nuke, although that’s a separate
discussion.
I would suggest the stats update should always be pushed at the same time
as the change that would otherwise break the regressions. Anytime someone
does a pull all regressions should pass. As simple as that.
The challenge with distributing test binaries is licenses, and sheer size.
I agree it would be good to have something openly available, and have
precompiled binaries in a separate repository or a tarball. Any
suggestions are welcome. Until we have something to replace the current
ones we need to stick to what we have...
For the FS ones you don’t have to modify anything, just set M5_PATH.
Andreas
On 27/08/2015 20:10, "gem5-dev on behalf of Joel Hestness"
Post by Joel Hestness
Post by Andreas Hansson
On zizzer you should be able to run it without any issues. For systems
other than zizzer, the FS regressions need the FS files from the download
section on the wiki. As you point out, the cpu2000 tests rely on binaries
we cannot distribute :-(.
I see. A big part of my misunderstanding then is that I've never had access
to Zizzer, though I've had gem5 commit access since 2011. Is there a
process in place for getting access to Zizzer and running regressions there?
Post by Andreas Hansson
A full regression run covers all ISAs and tests, not just quick. This is
around 50-60 host CPU hours.
Hm, I was not aware that this was the community's plan. This seems pretty
unclear to me. For instance, the gem5 submission wiki page (
http://gem5.org/Submitting_Contributions) lacks precise information about
which tests must be working and updated, and only states that quick tests
must be run. It doesn't include anything about updating the regressions,
which ones, or when the updates need to take place.
Assuming all committers are on the same page about what constitutes "full
regressions", I'll volunteer to update the page to clarify that the
committer is responsible for updating all regressions as appropriate when a
change is committed. Do we want to set a specific timeline for this (e.g.
within the same set of changesets that change regressions, or within the
next X days)?
1) It is also currently unclear which tests are required based on the
daily cron regressions emails, and especially since the do-regression
script isn't available in gem5. At a minimum, we should update scons or
do-regression on Zizzer to print all regression test names daily. Another
good thing to do is to include do-regression in gem5, so all contributors
can see how regressions are run. If we decide not to run full regressions
daily, those that are not run (but need to be as part of a "full
regression") should be marked with something more descriptive than
"skipped" like the currently tracing regressions (eio, tgen).
2) ::Expanding on my prior email:: If we formalize "full regressions" to
include all tests, then we *really* need to include full, out-of-the-box
runable regressions within the gem5 repo or at least using nicely packaged
binaries/disks in a tar file (NOTE: even the FS files tarball requires
modifying configs/common/SysPaths.py so the simulator can find the files).
It should be possible for both committers AND patch contributors to run the
full regression suite (not just those committers with access to Zizzer).
Otherwise, it seems like an unreasonable expectation for committers with
access to Zizzer to completely manage regression test updates.
Probably also makes sense to firm up and document committer/Zizzer access
and regression plans while I go through as a partial guinea pig.
Joel
On 27/08/2015 14:34, "gem5-dev on behalf of Joel Hestness"
Post by Andreas Hansson
Post by Joel Hestness
Hi Andreas,
Yes, I agree that committers should run full regressions (i.e. all
quick
Post by Joel Hestness
tests that are verified daily on Zizzer, right?). I ran quick
regressions
Post by Joel Hestness
that are configured correctly, and they pass with this patch.
The problem with running all quick regressions currently is that
many
Post by Joel Hestness
tests don't run out-of-the-box, and I haven't found instructions on
how to
Post by Joel Hestness
set up tests like the cpu2000 and FS tests. I made a request for such
I'm totally willing to run all the quick regressions and update as
appropriate, but I'd like more information on these. How does one set
up
Post by Joel Hestness
FS
and cpu2000 tests? Can we include Linux binaries in the tests/
directory
Post by Joel Hestness
so
those tests can run out-of-the-box? Can we change the cpu2000 tests to some
other benchmarks without distribution restrictions, so they too can be
included in tests/?
Thanks,
Joel
On Thu, Aug 27, 2015 at 7:19 AM, Andreas Hansson
Post by Andreas Hansson
Hi Joel,
It seems the patch from Emilio changes a few of the full system
regressions. I merely wanted to check if you simply forgot to push a stats
update?
In general I would expect anyone pushing patches to do a full
regression
Post by Joel Hestness
Post by Andreas Hansson
run (and sanity check any changes). Agreed?
Thanks,
Andreas
-- IMPORTANT NOTICE: The contents of this email and any attachments
are
Post by Joel Hestness
Post by Andreas Hansson
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose
the
Post by Joel Hestness
Post by Andreas Hansson
contents to any other person, use it for any purpose, or store or
copy
Post by Joel Hestness
Post by Andreas Hansson
the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- 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.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
ecastill
2015-08-28 07:59:02 UTC
Permalink
Hello,

First of all, sorry for all the problems that the patch is causing.
The main issue that it aimed to solve is that when a Quiesce inst is
fetched, the fetch Stage completely blocks (the IsQuiesce flag in the
ISA decoder).
If the quiesce wake event is not created, the cpu will hang and never
wake up.

In the X86 arch. the kernel that we (and most of the user base) use,
seems to execute quiesce insts with a value of 0 ns, deadlocking the o3
CPU.
I have been using this patch in my own gem5 for several months already
and hadn't noticed any increase in the exec time nor the executed
instructions.
I am surprised at the outcome with ARM.

The only thing the patch do is to schedule a wake event, thus the
assumptions are that it should add a negligible overhead.
Do the ARM FS tests execute quiesce instructions of 0ns?, maybe the
semantics are a bit different and means something like sleep until
interrupt.
(I am completely blind when it comes to ARM). This could explain this
behaviour.

Sorry again,

Regards
Post by Andreas Hansson
More problems in paradise.
It turns out, on a full regression run, that the particular changeset
causes a massive increase in the run-time (30%) and instruction count for
build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview64-o3 and
build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview64-o3-checker.
I suspect some interrupt/quiesce oddity, or even bug. Note that these are
already some of our longest running regressions (3+ hours), and this
change just added 1 hour to each of them.
I am not sure what to suggest. The run-time increase is troublesome, the
fact that such a small change suddenly adds 30% to the instruction count
of a single-core regression is even more alarming. Joel, any ideas? Anyone
else?
Andreas
On 27/08/2015 22:12, "gem5-dev on behalf of Andreas Hansson"
Post by Andreas Hansson
Hi Joel,
I always run util/regress with ‘all'. This will build all ISAs and run all
tests. You shouldn’t need anything else imho.
Preferably make sure you have protobuf so that the tgen tests are run as
well. Eio I agree we should probably nuke, although that’s a separate
discussion.
I would suggest the stats update should always be pushed at the same time
as the change that would otherwise break the regressions. Anytime someone
does a pull all regressions should pass. As simple as that.
The challenge with distributing test binaries is licenses, and sheer size.
I agree it would be good to have something openly available, and have
precompiled binaries in a separate repository or a tarball. Any
suggestions are welcome. Until we have something to replace the current
ones we need to stick to what we have...
For the FS ones you don’t have to modify anything, just set M5_PATH.
Andreas
On 27/08/2015 20:10, "gem5-dev on behalf of Joel Hestness"
Post by Joel Hestness
Post by Andreas Hansson
On zizzer you should be able to run it without any issues. For systems
other than zizzer, the FS regressions need the FS files from the download
section on the wiki. As you point out, the cpu2000 tests rely on binaries
we cannot distribute :-(.
I see. A big part of my misunderstanding then is that I've never had access
to Zizzer, though I've had gem5 commit access since 2011. Is there a
process in place for getting access to Zizzer and running regressions there?
Post by Andreas Hansson
A full regression run covers all ISAs and tests, not just quick. This is
around 50-60 host CPU hours.
Hm, I was not aware that this was the community's plan. This seems pretty
unclear to me. For instance, the gem5 submission wiki page (
http://gem5.org/Submitting_Contributions) lacks precise information about
which tests must be working and updated, and only states that quick tests
must be run. It doesn't include anything about updating the regressions,
which ones, or when the updates need to take place.
Assuming all committers are on the same page about what constitutes "full
regressions", I'll volunteer to update the page to clarify that the
committer is responsible for updating all regressions as appropriate when a
change is committed. Do we want to set a specific timeline for this (e.g.
within the same set of changesets that change regressions, or within the
next X days)?
1) It is also currently unclear which tests are required based on the
daily cron regressions emails, and especially since the do-regression
script isn't available in gem5. At a minimum, we should update scons or
do-regression on Zizzer to print all regression test names daily. Another
good thing to do is to include do-regression in gem5, so all contributors
can see how regressions are run. If we decide not to run full regressions
daily, those that are not run (but need to be as part of a "full
regression") should be marked with something more descriptive than
"skipped" like the currently tracing regressions (eio, tgen).
2) ::Expanding on my prior email:: If we formalize "full regressions" to
include all tests, then we *really* need to include full, out-of-the-box
runable regressions within the gem5 repo or at least using nicely packaged
binaries/disks in a tar file (NOTE: even the FS files tarball requires
modifying configs/common/SysPaths.py so the simulator can find the files).
It should be possible for both committers AND patch contributors to run the
full regression suite (not just those committers with access to Zizzer).
Otherwise, it seems like an unreasonable expectation for committers with
access to Zizzer to completely manage regression test updates.
Probably also makes sense to firm up and document committer/Zizzer access
and regression plans while I go through as a partial guinea pig.
Joel
On 27/08/2015 14:34, "gem5-dev on behalf of Joel Hestness"
Post by Andreas Hansson
Post by Joel Hestness
Hi Andreas,
Yes, I agree that committers should run full regressions (i.e. all
quick
Post by Joel Hestness
tests that are verified daily on Zizzer, right?). I ran quick
regressions
Post by Joel Hestness
that are configured correctly, and they pass with this patch.
The problem with running all quick regressions currently is that
many
Post by Joel Hestness
tests don't run out-of-the-box, and I haven't found instructions on
how to
Post by Joel Hestness
set up tests like the cpu2000 and FS tests. I made a request for such
I'm totally willing to run all the quick regressions and update as
appropriate, but I'd like more information on these. How does one set
up
Post by Joel Hestness
FS
and cpu2000 tests? Can we include Linux binaries in the tests/
directory
Post by Joel Hestness
so
those tests can run out-of-the-box? Can we change the cpu2000 tests to some
other benchmarks without distribution restrictions, so they too can be
included in tests/?
Thanks,
Joel
On Thu, Aug 27, 2015 at 7:19 AM, Andreas Hansson
Post by Andreas Hansson
Hi Joel,
It seems the patch from Emilio changes a few of the full system
regressions. I merely wanted to check if you simply forgot to push a stats
update?
In general I would expect anyone pushing patches to do a full
regression
Post by Joel Hestness
Post by Andreas Hansson
run (and sanity check any changes). Agreed?
Thanks,
Andreas
-- IMPORTANT NOTICE: The contents of this email and any attachments
are
Post by Joel Hestness
Post by Andreas Hansson
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose
the
Post by Joel Hestness
Post by Andreas Hansson
contents to any other person, use it for any purpose, or store or
copy
Post by Joel Hestness
Post by Andreas Hansson
the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.

http://www.bsc.es/disclaimer
Joel Hestness
2015-08-28 15:58:33 UTC
Permalink
Hi Andreas,
I also saw the 30% instruction increase in these tests this morning. Am
currently looking into it.

On first read, it seems that the UDelayEvent (src/kern/linux/events.hh
used in src/arch/arm/linux/system.cc:84-88) must be where the extra
quiesceNs calls are originating since the kernel's timer/delay
functionality appears to be unmodified (correct?). It looks like ARM
hijacks the __udelay, __loop_udelay, and __loop_const_udelay kernel
functions, swapping them with these UDelayEvents within the simulator.
Since the quiesceNs function now suspends the CPU and reactivates it with
an EndQuiesceEvent, it is likely that the increase in instructions a result
of spinning that these events skipped.

I still feel strongly that every started quiesce event should result in
an EndQuiesceEvent and that this patch should change. Changeset 10341 (
http://repo.gem5.org/gem5/rev/0b4d10f53c2d) introduced this requirement.
UDelayEvents do not start a quiesce until after the event is complete, and
they directly call PseudoInst::quiesceNs, which I believe to be the
funkiest use of the function in the codebase. I am testing a fix that
conditionally calls quiesceNs from UDelayEvent::process() only if the delay
is >0.

Will keep you posted,
Joel
Post by ecastill
Hello,
First of all, sorry for all the problems that the patch is causing.
The main issue that it aimed to solve is that when a Quiesce inst is
fetched, the fetch Stage completely blocks (the IsQuiesce flag in the ISA
decoder).
If the quiesce wake event is not created, the cpu will hang and never wake
up.
In the X86 arch. the kernel that we (and most of the user base) use, seems
to execute quiesce insts with a value of 0 ns, deadlocking the o3 CPU.
I have been using this patch in my own gem5 for several months already and
hadn't noticed any increase in the exec time nor the executed instructions.
I am surprised at the outcome with ARM.
The only thing the patch do is to schedule a wake event, thus the
assumptions are that it should add a negligible overhead.
Do the ARM FS tests execute quiesce instructions of 0ns?, maybe the
semantics are a bit different and means something like sleep until
interrupt.
(I am completely blind when it comes to ARM). This could explain this
behaviour.
Sorry again,
Regards
Post by Andreas Hansson
More problems in paradise.
It turns out, on a full regression run, that the particular changeset
causes a massive increase in the run-time (30%) and instruction count for
build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview64-o3 and
build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview64-o3-checker.
I suspect some interrupt/quiesce oddity, or even bug. Note that these are
already some of our longest running regressions (3+ hours), and this
change just added 1 hour to each of them.
I am not sure what to suggest. The run-time increase is troublesome, the
fact that such a small change suddenly adds 30% to the instruction count
of a single-core regression is even more alarming. Joel, any ideas? Anyone
else?
Andreas
On 27/08/2015 22:12, "gem5-dev on behalf of Andreas Hansson"
Hi Joel,
Post by Andreas Hansson
I always run util/regress with ‘all'. This will build all ISAs and run all
tests. You shouldn’t need anything else imho.
Preferably make sure you have protobuf so that the tgen tests are run as
well. Eio I agree we should probably nuke, although that’s a separate
discussion.
I would suggest the stats update should always be pushed at the same time
as the change that would otherwise break the regressions. Anytime someone
does a pull all regressions should pass. As simple as that.
The challenge with distributing test binaries is licenses, and sheer size.
I agree it would be good to have something openly available, and have
precompiled binaries in a separate repository or a tarball. Any
suggestions are welcome. Until we have something to replace the current
ones we need to stick to what we have...
For the FS ones you don’t have to modify anything, just set M5_PATH.
Andreas
On 27/08/2015 20:10, "gem5-dev on behalf of Joel Hestness"
On zizzer you should be able to run it without any issues. For systems
Post by Joel Hestness
Post by Andreas Hansson
other than zizzer, the FS regressions need the FS files from the download
section on the wiki. As you point out, the cpu2000 tests rely on binaries
we cannot distribute :-(.
I see. A big part of my misunderstanding then is that I've never had
access
to Zizzer, though I've had gem5 commit access since 2011. Is there a
process in place for getting access to Zizzer and running regressions there?
A full regression run covers all ISAs and tests, not just quick. This
Post by Andreas Hansson
is
around 50-60 host CPU hours.
Hm, I was not aware that this was the community's plan. This seems pretty
unclear to me. For instance, the gem5 submission wiki page (
http://gem5.org/Submitting_Contributions) lacks precise information about
which tests must be working and updated, and only states that quick tests
must be run. It doesn't include anything about updating the regressions,
which ones, or when the updates need to take place.
Assuming all committers are on the same page about what constitutes "full
regressions", I'll volunteer to update the page to clarify that the
committer is responsible for updating all regressions as appropriate
when
a
change is committed. Do we want to set a specific timeline for this (e.g.
within the same set of changesets that change regressions, or within the
next X days)?
1) It is also currently unclear which tests are required based on the
daily cron regressions emails, and especially since the do-regression
script isn't available in gem5. At a minimum, we should update scons or
do-regression on Zizzer to print all regression test names daily. Another
good thing to do is to include do-regression in gem5, so all contributors
can see how regressions are run. If we decide not to run full regressions
daily, those that are not run (but need to be as part of a "full
regression") should be marked with something more descriptive than
"skipped" like the currently tracing regressions (eio, tgen).
2) ::Expanding on my prior email:: If we formalize "full regressions" to
include all tests, then we *really* need to include full, out-of-the-box
runable regressions within the gem5 repo or at least using nicely packaged
binaries/disks in a tar file (NOTE: even the FS files tarball requires
modifying configs/common/SysPaths.py so the simulator can find the files).
It should be possible for both committers AND patch contributors to run the
full regression suite (not just those committers with access to Zizzer).
Otherwise, it seems like an unreasonable expectation for committers with
access to Zizzer to completely manage regression test updates.
Probably also makes sense to firm up and document committer/Zizzer access
and regression plans while I go through as a partial guinea pig.
Joel
On 27/08/2015 14:34, "gem5-dev on behalf of Joel Hestness"
Post by Andreas Hansson
Hi Andreas,
Post by Joel Hestness
Yes, I agree that committers should run full regressions (i.e. all
quick
Post by Joel Hestness
tests that are verified daily on Zizzer, right?). I ran quick
regressions
Post by Joel Hestness
that are configured correctly, and they pass with this patch.
The problem with running all quick regressions currently is that
many
Post by Joel Hestness
tests don't run out-of-the-box, and I haven't found instructions on
how to
Post by Joel Hestness
set up tests like the cpu2000 and FS tests. I made a request for such
I'm totally willing to run all the quick regressions and update as
appropriate, but I'd like more information on these. How does one set
up
Post by Joel Hestness
FS
and cpu2000 tests? Can we include Linux binaries in the tests/
directory
Post by Joel Hestness
so
those tests can run out-of-the-box? Can we change the cpu2000 tests to some
other benchmarks without distribution restrictions, so they too can be
included in tests/?
Thanks,
Joel
On Thu, Aug 27, 2015 at 7:19 AM, Andreas Hansson
Hi Joel,
Post by Andreas Hansson
It seems the patch from Emilio changes a few of the full system
regressions. I merely wanted to check if you simply forgot to push a stats
update?
In general I would expect anyone pushing patches to do a full
regression
run (and sanity check any changes). Agreed?
Post by Andreas Hansson
Thanks,
Andreas
-- IMPORTANT NOTICE: The contents of this email and any attachments
are
confidential and may also be privileged. If you are not the intended
Post by Andreas Hansson
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
Post by Andreas Hansson
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.
http://www.bsc.es/disclaimer
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
Mitch Hayenga
2015-08-28 19:03:12 UTC
Permalink
Re: Changeset 10341

We didn’t introduce the use of the function, we appended flags such that o3
properly handled the existing use of these functions.

I added this because x86 regressions were crashing on o3 after some unrelated
changes. Basically, o3 requires an instruction to be flagged as
IsQuiesce() if it has the ability to suspend execution. This is because o3
can leave instructions in various time buffers, etc in flight. If the CPU
happens to get ticked before it is properly woken up (this did happen back
when this patch was made), those in-flight instructions would be lost. So,
effectively the the IsQuiesce() works as a mini-barrier/drain, not letting
younger instructions into the out-of-order backend of o3.

I remember that after writing/submitting this patch we saw the # of
instructions
on x86 regressions drastically drop on some regressions. This was because
important, after-quiesce, instructions were no longer being dropped
Post by Joel Hestness
Hi Andreas,
I also saw the 30% instruction increase in these tests this morning. Am
currently looking into it.
On first read, it seems that the UDelayEvent (src/kern/linux/events.hh
used in src/arch/arm/linux/system.cc:84-88) must be where the extra
quiesceNs calls are originating since the kernel's timer/delay
functionality appears to be unmodified (correct?). It looks like ARM
hijacks the __udelay, __loop_udelay, and __loop_const_udelay kernel
functions, swapping them with these UDelayEvents within the simulator.
Since the quiesceNs function now suspends the CPU and reactivates it with
an EndQuiesceEvent, it is likely that the increase in instructions a result
of spinning that these events skipped.
I still feel strongly that every started quiesce event should result in
an EndQuiesceEvent and that this patch should change. Changeset 10341 (
http://repo.gem5.org/gem5/rev/0b4d10f53c2d) introduced this requirement.
UDelayEvents do not start a quiesce until after the event is complete, and
they directly call PseudoInst::quiesceNs, which I believe to be the
funkiest use of the function in the codebase. I am testing a fix that
conditionally calls quiesceNs from UDelayEvent::process() only if the delay
is >0.
Will keep you posted,
Joel
Post by ecastill
Hello,
First of all, sorry for all the problems that the patch is causing.
The main issue that it aimed to solve is that when a Quiesce inst is
fetched, the fetch Stage completely blocks (the IsQuiesce flag in the ISA
decoder).
If the quiesce wake event is not created, the cpu will hang and never
wake
Post by ecastill
up.
In the X86 arch. the kernel that we (and most of the user base) use,
seems
Post by ecastill
to execute quiesce insts with a value of 0 ns, deadlocking the o3 CPU.
I have been using this patch in my own gem5 for several months already
and
Post by ecastill
hadn't noticed any increase in the exec time nor the executed
instructions.
Post by ecastill
I am surprised at the outcome with ARM.
The only thing the patch do is to schedule a wake event, thus the
assumptions are that it should add a negligible overhead.
Do the ARM FS tests execute quiesce instructions of 0ns?, maybe the
semantics are a bit different and means something like sleep until
interrupt.
(I am completely blind when it comes to ARM). This could explain this
behaviour.
Sorry again,
Regards
Post by Andreas Hansson
More problems in paradise.
It turns out, on a full regression run, that the particular changeset
causes a massive increase in the run-time (30%) and instruction count
for
Post by ecastill
Post by Andreas Hansson
build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview64-o3 and
build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview64-o3-checker.
Post by ecastill
Post by Andreas Hansson
I suspect some interrupt/quiesce oddity, or even bug. Note that these
are
Post by ecastill
Post by Andreas Hansson
already some of our longest running regressions (3+ hours), and this
change just added 1 hour to each of them.
I am not sure what to suggest. The run-time increase is troublesome, the
fact that such a small change suddenly adds 30% to the instruction count
of a single-core regression is even more alarming. Joel, any ideas?
Anyone
Post by ecastill
Post by Andreas Hansson
else?
Andreas
On 27/08/2015 22:12, "gem5-dev on behalf of Andreas Hansson"
Hi Joel,
Post by Andreas Hansson
I always run util/regress with ‘all'. This will build all ISAs and run all
tests. You shouldn’t need anything else imho.
Preferably make sure you have protobuf so that the tgen tests are run
as
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
well. Eio I agree we should probably nuke, although that’s a separate
discussion.
I would suggest the stats update should always be pushed at the same
time
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
as the change that would otherwise break the regressions. Anytime
someone
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
does a pull all regressions should pass. As simple as that.
The challenge with distributing test binaries is licenses, and sheer size.
I agree it would be good to have something openly available, and have
precompiled binaries in a separate repository or a tarball. Any
suggestions are welcome. Until we have something to replace the current
ones we need to stick to what we have...
For the FS ones you don’t have to modify anything, just set M5_PATH.
Andreas
On 27/08/2015 20:10, "gem5-dev on behalf of Joel Hestness"
On zizzer you should be able to run it without any issues. For systems
Post by Joel Hestness
Post by Andreas Hansson
other than zizzer, the FS regressions need the FS files from the download
section on the wiki. As you point out, the cpu2000 tests rely on binaries
we cannot distribute :-(.
I see. A big part of my misunderstanding then is that I've never had
access
to Zizzer, though I've had gem5 commit access since 2011. Is there a
process in place for getting access to Zizzer and running regressions there?
A full regression run covers all ISAs and tests, not just quick. This
Post by Andreas Hansson
is
around 50-60 host CPU hours.
Hm, I was not aware that this was the community's plan. This seems pretty
unclear to me. For instance, the gem5 submission wiki page (
http://gem5.org/Submitting_Contributions) lacks precise information about
which tests must be working and updated, and only states that quick tests
must be run. It doesn't include anything about updating the
regressions,
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
which ones, or when the updates need to take place.
Assuming all committers are on the same page about what constitutes "full
regressions", I'll volunteer to update the page to clarify that the
committer is responsible for updating all regressions as appropriate
when
a
change is committed. Do we want to set a specific timeline for this (e.g.
within the same set of changesets that change regressions, or within
the
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
next X days)?
1) It is also currently unclear which tests are required based on the
daily cron regressions emails, and especially since the do-regression
script isn't available in gem5. At a minimum, we should update scons
or
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
do-regression on Zizzer to print all regression test names daily. Another
good thing to do is to include do-regression in gem5, so all contributors
can see how regressions are run. If we decide not to run full regressions
daily, those that are not run (but need to be as part of a "full
regression") should be marked with something more descriptive than
"skipped" like the currently tracing regressions (eio, tgen).
2) ::Expanding on my prior email:: If we formalize "full regressions"
to
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
include all tests, then we *really* need to include full,
out-of-the-box
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
runable regressions within the gem5 repo or at least using nicely packaged
binaries/disks in a tar file (NOTE: even the FS files tarball requires
modifying configs/common/SysPaths.py so the simulator can find the files).
It should be possible for both committers AND patch contributors to
run
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
the
full regression suite (not just those committers with access to
Zizzer).
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Otherwise, it seems like an unreasonable expectation for committers
with
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
access to Zizzer to completely manage regression test updates.
Probably also makes sense to firm up and document committer/Zizzer access
and regression plans while I go through as a partial guinea pig.
Joel
On 27/08/2015 14:34, "gem5-dev on behalf of Joel Hestness"
Post by Andreas Hansson
Hi Andreas,
Post by Joel Hestness
Yes, I agree that committers should run full regressions (i.e. all
quick
Post by Joel Hestness
tests that are verified daily on Zizzer, right?). I ran quick
regressions
Post by Joel Hestness
that are configured correctly, and they pass with this patch.
The problem with running all quick regressions currently is that
many
Post by Joel Hestness
tests don't run out-of-the-box, and I haven't found instructions on
how to
Post by Joel Hestness
set up tests like the cpu2000 and FS tests. I made a request for
such
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
I'm totally willing to run all the quick regressions and update as
appropriate, but I'd like more information on these. How does one
set
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
up
Post by Joel Hestness
FS
and cpu2000 tests? Can we include Linux binaries in the tests/
directory
Post by Joel Hestness
so
those tests can run out-of-the-box? Can we change the cpu2000 tests
to
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
some
other benchmarks without distribution restrictions, so they too can
be
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
included in tests/?
Thanks,
Joel
On Thu, Aug 27, 2015 at 7:19 AM, Andreas Hansson
Hi Joel,
Post by Andreas Hansson
It seems the patch from Emilio changes a few of the full system
regressions. I merely wanted to check if you simply forgot to push
a
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
stats
update?
In general I would expect anyone pushing patches to do a full
regression
run (and sanity check any changes). Agreed?
Post by Andreas Hansson
Thanks,
Andreas
-- IMPORTANT NOTICE: The contents of this email and any attachments
are
confidential and may also be privileged. If you are not the intended
Post by Andreas Hansson
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
Post by Andreas Hansson
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ,
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge
CB1
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments
are
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose
the
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
contents to any other person, use it for any purpose, or store or
copy
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ,
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- 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
Post by ecastill
Post by Andreas Hansson
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ,
Post by ecastill
Post by Andreas Hansson
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.
http://www.bsc.es/disclaimer
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
Joel Hestness
2015-08-28 19:33:45 UTC
Permalink
Hi guys,

@Mitch: Thanks for the detail. My argument is that introduction of the
IsQuiesce instruction property in changeset 10341 now requires that if an
IsQuiesce instruction is executed (i.e. a quiesce process is started), then
a following EndQuiesceEvent *must* get scheduled and executed to wake up
the CPU core.

@All: I just posted a patch that fixes the ARM use of UDelayEvents and
returns the regression instructions and run time back to what it was.
Please check it out: http://reviews.gem5.org/r/3077/

Joel
Post by Mitch Hayenga
Re: Changeset 10341
We didn’t introduce the use of the function, we appended flags such that o3
properly handled the existing use of these functions.
I added this because x86 regressions were crashing on o3 after some unrelated
changes. Basically, o3 requires an instruction to be flagged as
IsQuiesce() if it has the ability to suspend execution. This is because o3
can leave instructions in various time buffers, etc in flight. If the CPU
happens to get ticked before it is properly woken up (this did happen back
when this patch was made), those in-flight instructions would be lost. So,
effectively the the IsQuiesce() works as a mini-barrier/drain, not letting
younger instructions into the out-of-order backend of o3.
I remember that after writing/submitting this patch we saw the # of
instructions
on x86 regressions drastically drop on some regressions. This was because
important, after-quiesce, instructions were no longer being dropped
Post by Joel Hestness
Hi Andreas,
I also saw the 30% instruction increase in these tests this morning. Am
currently looking into it.
On first read, it seems that the UDelayEvent (src/kern/linux/events.hh
used in src/arch/arm/linux/system.cc:84-88) must be where the extra
quiesceNs calls are originating since the kernel's timer/delay
functionality appears to be unmodified (correct?). It looks like ARM
hijacks the __udelay, __loop_udelay, and __loop_const_udelay kernel
functions, swapping them with these UDelayEvents within the simulator.
Since the quiesceNs function now suspends the CPU and reactivates it with
an EndQuiesceEvent, it is likely that the increase in instructions a
result
Post by Joel Hestness
of spinning that these events skipped.
I still feel strongly that every started quiesce event should result in
an EndQuiesceEvent and that this patch should change. Changeset 10341 (
http://repo.gem5.org/gem5/rev/0b4d10f53c2d) introduced this requirement.
UDelayEvents do not start a quiesce until after the event is complete,
and
Post by Joel Hestness
they directly call PseudoInst::quiesceNs, which I believe to be the
funkiest use of the function in the codebase. I am testing a fix that
conditionally calls quiesceNs from UDelayEvent::process() only if the
delay
Post by Joel Hestness
is >0.
Will keep you posted,
Joel
Post by ecastill
Hello,
First of all, sorry for all the problems that the patch is causing.
The main issue that it aimed to solve is that when a Quiesce inst is
fetched, the fetch Stage completely blocks (the IsQuiesce flag in the
ISA
Post by Joel Hestness
Post by ecastill
decoder).
If the quiesce wake event is not created, the cpu will hang and never
wake
Post by ecastill
up.
In the X86 arch. the kernel that we (and most of the user base) use,
seems
Post by ecastill
to execute quiesce insts with a value of 0 ns, deadlocking the o3 CPU.
I have been using this patch in my own gem5 for several months already
and
Post by ecastill
hadn't noticed any increase in the exec time nor the executed
instructions.
Post by ecastill
I am surprised at the outcome with ARM.
The only thing the patch do is to schedule a wake event, thus the
assumptions are that it should add a negligible overhead.
Do the ARM FS tests execute quiesce instructions of 0ns?, maybe the
semantics are a bit different and means something like sleep until
interrupt.
(I am completely blind when it comes to ARM). This could explain this
behaviour.
Sorry again,
Regards
Post by Andreas Hansson
More problems in paradise.
It turns out, on a full regression run, that the particular changeset
causes a massive increase in the run-time (30%) and instruction count
for
Post by ecastill
Post by Andreas Hansson
build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview64-o3 and
build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview64-o3-checker.
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
I suspect some interrupt/quiesce oddity, or even bug. Note that these
are
Post by ecastill
Post by Andreas Hansson
already some of our longest running regressions (3+ hours), and this
change just added 1 hour to each of them.
I am not sure what to suggest. The run-time increase is troublesome,
the
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
fact that such a small change suddenly adds 30% to the instruction
count
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
of a single-core regression is even more alarming. Joel, any ideas?
Anyone
Post by ecastill
Post by Andreas Hansson
else?
Andreas
On 27/08/2015 22:12, "gem5-dev on behalf of Andreas Hansson"
Hi Joel,
Post by Andreas Hansson
I always run util/regress with ‘all'. This will build all ISAs and
run
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
all
tests. You shouldn’t need anything else imho.
Preferably make sure you have protobuf so that the tgen tests are run
as
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
well. Eio I agree we should probably nuke, although that’s a separate
discussion.
I would suggest the stats update should always be pushed at the same
time
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
as the change that would otherwise break the regressions. Anytime
someone
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
does a pull all regressions should pass. As simple as that.
The challenge with distributing test binaries is licenses, and sheer size.
I agree it would be good to have something openly available, and have
precompiled binaries in a separate repository or a tarball. Any
suggestions are welcome. Until we have something to replace the
current
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
ones we need to stick to what we have...
For the FS ones you don’t have to modify anything, just set M5_PATH.
Andreas
On 27/08/2015 20:10, "gem5-dev on behalf of Joel Hestness"
On zizzer you should be able to run it without any issues. For
systems
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
other than zizzer, the FS regressions need the FS files from the download
section on the wiki. As you point out, the cpu2000 tests rely on binaries
we cannot distribute :-(.
I see. A big part of my misunderstanding then is that I've never
had
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
access
to Zizzer, though I've had gem5 commit access since 2011. Is there a
process in place for getting access to Zizzer and running
regressions
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
there?
A full regression run covers all ISAs and tests, not just quick.
This
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
is
around 50-60 host CPU hours.
Hm, I was not aware that this was the community's plan. This seems pretty
unclear to me. For instance, the gem5 submission wiki page (
http://gem5.org/Submitting_Contributions) lacks precise information about
which tests must be working and updated, and only states that quick tests
must be run. It doesn't include anything about updating the
regressions,
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
which ones, or when the updates need to take place.
Assuming all committers are on the same page about what constitutes "full
regressions", I'll volunteer to update the page to clarify that the
committer is responsible for updating all regressions as appropriate
when
a
change is committed. Do we want to set a specific timeline for this (e.g.
within the same set of changesets that change regressions, or within
the
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
next X days)?
1) It is also currently unclear which tests are required based on
the
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
daily cron regressions emails, and especially since the
do-regression
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
script isn't available in gem5. At a minimum, we should update scons
or
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
do-regression on Zizzer to print all regression test names daily. Another
good thing to do is to include do-regression in gem5, so all contributors
can see how regressions are run. If we decide not to run full regressions
daily, those that are not run (but need to be as part of a "full
regression") should be marked with something more descriptive than
"skipped" like the currently tracing regressions (eio, tgen).
2) ::Expanding on my prior email:: If we formalize "full
regressions"
Post by Joel Hestness
to
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
include all tests, then we *really* need to include full,
out-of-the-box
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
runable regressions within the gem5 repo or at least using nicely packaged
binaries/disks in a tar file (NOTE: even the FS files tarball
requires
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
modifying configs/common/SysPaths.py so the simulator can find the files).
It should be possible for both committers AND patch contributors to
run
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
the
full regression suite (not just those committers with access to
Zizzer).
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Otherwise, it seems like an unreasonable expectation for committers
with
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
access to Zizzer to completely manage regression test updates.
Probably also makes sense to firm up and document committer/Zizzer access
and regression plans while I go through as a partial guinea pig.
Joel
On 27/08/2015 14:34, "gem5-dev on behalf of Joel Hestness"
Post by Andreas Hansson
Hi Andreas,
Post by Joel Hestness
Yes, I agree that committers should run full regressions (i.e.
all
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
quick
Post by Joel Hestness
tests that are verified daily on Zizzer, right?). I ran quick
regressions
Post by Joel Hestness
that are configured correctly, and they pass with this patch.
The problem with running all quick regressions currently is that
many
Post by Joel Hestness
tests don't run out-of-the-box, and I haven't found instructions
on
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
how to
Post by Joel Hestness
set up tests like the cpu2000 and FS tests. I made a request for
such
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
I'm totally willing to run all the quick regressions and update
as
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
appropriate, but I'd like more information on these. How does one
set
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
up
Post by Joel Hestness
FS
and cpu2000 tests? Can we include Linux binaries in the tests/
directory
Post by Joel Hestness
so
those tests can run out-of-the-box? Can we change the cpu2000
tests
Post by Joel Hestness
to
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
some
other benchmarks without distribution restrictions, so they too
can
Post by Joel Hestness
be
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
included in tests/?
Thanks,
Joel
On Thu, Aug 27, 2015 at 7:19 AM, Andreas Hansson
Hi Joel,
Post by Andreas Hansson
It seems the patch from Emilio changes a few of the full system
regressions. I merely wanted to check if you simply forgot to
push
Post by Joel Hestness
a
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
stats
update?
In general I would expect anyone pushing patches to do a full
regression
run (and sanity check any changes). Agreed?
Post by Andreas Hansson
Thanks,
Andreas
-- IMPORTANT NOTICE: The contents of this email and any
attachments
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
are
confidential and may also be privileged. If you are not the
intended
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
recipient, please notify the sender immediately and do not
disclose
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
the
contents to any other person, use it for any purpose, or store or
copy
the
Post by Andreas Hansson
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ,
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge
CB1
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments
are
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
confidential and may also be privileged. If you are not the
intended
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
recipient, please notify the sender immediately and do not disclose
the
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
contents to any other person, use it for any purpose, or store or
copy
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ,
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge
CB1
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments
are
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose
the
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
contents to any other person, use it for any purpose, or store or
copy
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ,
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments
are
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose
the
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
contents to any other person, use it for any purpose, or store or copy
the
Post by ecastill
Post by Andreas Hansson
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ,
Post by ecastill
Post by Andreas Hansson
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.
http://www.bsc.es/disclaimer
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
Steve Reinhardt
2015-08-29 21:57:46 UTC
Permalink
I agree with a lot of the complaints/issues/suggestions about regressions
here. There's plenty of room for improvement. I would like to highlight
Andreas's comment about setting M5_PATH rather than editing SysPaths.py,
and point out that there's also an M5_TEST_PROGS environment variable
that's checked in tests/run.py when looking for non-FS regression
binaries. So regardless of where you put your downloaded binaries, there
shouldn't be a need to edit/patch gem5 itself to run the regressions, just
set the appropriate environment vars. (And if you don't want to do that
even, just put them all in /dist/m5 and use the default paths.)

Steve
Post by Joel Hestness
Hi guys,
@Mitch: Thanks for the detail. My argument is that introduction of the
IsQuiesce instruction property in changeset 10341 now requires that if an
IsQuiesce instruction is executed (i.e. a quiesce process is started), then
a following EndQuiesceEvent *must* get scheduled and executed to wake up
the CPU core.
@All: I just posted a patch that fixes the ARM use of UDelayEvents and
returns the regression instructions and run time back to what it was.
Please check it out: http://reviews.gem5.org/r/3077/
Joel
On Fri, Aug 28, 2015 at 2:03 PM, Mitch Hayenga <
Post by Mitch Hayenga
Re: Changeset 10341
We didn’t introduce the use of the function, we appended flags such that
o3
Post by Mitch Hayenga
properly handled the existing use of these functions.
I added this because x86 regressions were crashing on o3 after some unrelated
changes. Basically, o3 requires an instruction to be flagged as
IsQuiesce() if it has the ability to suspend execution. This is because
o3
Post by Mitch Hayenga
can leave instructions in various time buffers, etc in flight. If the
CPU
Post by Mitch Hayenga
happens to get ticked before it is properly woken up (this did happen
back
Post by Mitch Hayenga
when this patch was made), those in-flight instructions would be lost.
So,
Post by Mitch Hayenga
effectively the the IsQuiesce() works as a mini-barrier/drain, not
letting
Post by Mitch Hayenga
younger instructions into the out-of-order backend of o3.
I remember that after writing/submitting this patch we saw the # of
instructions
on x86 regressions drastically drop on some regressions. This was because
important, after-quiesce, instructions were no longer being dropped
Post by Joel Hestness
Hi Andreas,
I also saw the 30% instruction increase in these tests this morning.
Am
Post by Mitch Hayenga
Post by Joel Hestness
currently looking into it.
On first read, it seems that the UDelayEvent
(src/kern/linux/events.hh
Post by Mitch Hayenga
Post by Joel Hestness
used in src/arch/arm/linux/system.cc:84-88) must be where the extra
quiesceNs calls are originating since the kernel's timer/delay
functionality appears to be unmodified (correct?). It looks like ARM
hijacks the __udelay, __loop_udelay, and __loop_const_udelay kernel
functions, swapping them with these UDelayEvents within the simulator.
Since the quiesceNs function now suspends the CPU and reactivates it
with
Post by Mitch Hayenga
Post by Joel Hestness
an EndQuiesceEvent, it is likely that the increase in instructions a
result
Post by Joel Hestness
of spinning that these events skipped.
I still feel strongly that every started quiesce event should result
in
Post by Mitch Hayenga
Post by Joel Hestness
an EndQuiesceEvent and that this patch should change. Changeset 10341 (
http://repo.gem5.org/gem5/rev/0b4d10f53c2d) introduced this
requirement.
Post by Mitch Hayenga
Post by Joel Hestness
UDelayEvents do not start a quiesce until after the event is complete,
and
Post by Joel Hestness
they directly call PseudoInst::quiesceNs, which I believe to be the
funkiest use of the function in the codebase. I am testing a fix that
conditionally calls quiesceNs from UDelayEvent::process() only if the
delay
Post by Joel Hestness
is >0.
Will keep you posted,
Joel
Post by ecastill
Hello,
First of all, sorry for all the problems that the patch is causing.
The main issue that it aimed to solve is that when a Quiesce inst is
fetched, the fetch Stage completely blocks (the IsQuiesce flag in the
ISA
Post by Joel Hestness
Post by ecastill
decoder).
If the quiesce wake event is not created, the cpu will hang and never
wake
Post by ecastill
up.
In the X86 arch. the kernel that we (and most of the user base) use,
seems
Post by ecastill
to execute quiesce insts with a value of 0 ns, deadlocking the o3
CPU.
Post by Mitch Hayenga
Post by Joel Hestness
Post by ecastill
I have been using this patch in my own gem5 for several months
already
Post by Mitch Hayenga
Post by Joel Hestness
and
Post by ecastill
hadn't noticed any increase in the exec time nor the executed
instructions.
Post by ecastill
I am surprised at the outcome with ARM.
The only thing the patch do is to schedule a wake event, thus the
assumptions are that it should add a negligible overhead.
Do the ARM FS tests execute quiesce instructions of 0ns?, maybe the
semantics are a bit different and means something like sleep until
interrupt.
(I am completely blind when it comes to ARM). This could explain this
behaviour.
Sorry again,
Regards
Post by Andreas Hansson
More problems in paradise.
It turns out, on a full regression run, that the particular
changeset
Post by Mitch Hayenga
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
causes a massive increase in the run-time (30%) and instruction
count
Post by Mitch Hayenga
Post by Joel Hestness
for
Post by ecastill
Post by Andreas Hansson
build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview64-o3
and
build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview64-o3-checker.
Post by Mitch Hayenga
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
I suspect some interrupt/quiesce oddity, or even bug. Note that
these
Post by Mitch Hayenga
Post by Joel Hestness
are
Post by ecastill
Post by Andreas Hansson
already some of our longest running regressions (3+ hours), and this
change just added 1 hour to each of them.
I am not sure what to suggest. The run-time increase is troublesome,
the
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
fact that such a small change suddenly adds 30% to the instruction
count
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
of a single-core regression is even more alarming. Joel, any ideas?
Anyone
Post by ecastill
Post by Andreas Hansson
else?
Andreas
On 27/08/2015 22:12, "gem5-dev on behalf of Andreas Hansson"
Hi Joel,
Post by Andreas Hansson
I always run util/regress with ‘all'. This will build all ISAs and
run
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
all
tests. You shouldn’t need anything else imho.
Preferably make sure you have protobuf so that the tgen tests are
run
Post by Mitch Hayenga
Post by Joel Hestness
as
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
well. Eio I agree we should probably nuke, although that’s a
separate
Post by Mitch Hayenga
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
discussion.
I would suggest the stats update should always be pushed at the
same
Post by Mitch Hayenga
Post by Joel Hestness
time
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
as the change that would otherwise break the regressions. Anytime
someone
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
does a pull all regressions should pass. As simple as that.
The challenge with distributing test binaries is licenses, and
sheer
Post by Mitch Hayenga
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
size.
I agree it would be good to have something openly available, and
have
Post by Mitch Hayenga
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
precompiled binaries in a separate repository or a tarball. Any
suggestions are welcome. Until we have something to replace the
current
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
ones we need to stick to what we have...
For the FS ones you don’t have to modify anything, just set
M5_PATH.
Post by Mitch Hayenga
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Andreas
On 27/08/2015 20:10, "gem5-dev on behalf of Joel Hestness"
On zizzer you should be able to run it without any issues. For
systems
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
other than zizzer, the FS regressions need the FS files from the
download
section on the wiki. As you point out, the cpu2000 tests rely on
binaries
we cannot distribute :-(.
I see. A big part of my misunderstanding then is that I've never
had
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
access
to Zizzer, though I've had gem5 commit access since 2011. Is
there a
Post by Mitch Hayenga
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
process in place for getting access to Zizzer and running
regressions
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
there?
A full regression run covers all ISAs and tests, not just quick.
This
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
is
around 50-60 host CPU hours.
Hm, I was not aware that this was the community's plan. This seems pretty
unclear to me. For instance, the gem5 submission wiki page (
http://gem5.org/Submitting_Contributions) lacks precise
information
Post by Mitch Hayenga
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
about
which tests must be working and updated, and only states that
quick
Post by Mitch Hayenga
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
tests
must be run. It doesn't include anything about updating the
regressions,
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
which ones, or when the updates need to take place.
Assuming all committers are on the same page about what
constitutes
Post by Mitch Hayenga
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
"full
regressions", I'll volunteer to update the page to clarify that
the
Post by Mitch Hayenga
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
committer is responsible for updating all regressions as
appropriate
Post by Mitch Hayenga
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
when
a
change is committed. Do we want to set a specific timeline for
this
Post by Mitch Hayenga
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
(e.g.
within the same set of changesets that change regressions, or
within
Post by Mitch Hayenga
Post by Joel Hestness
the
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
next X days)?
1) It is also currently unclear which tests are required based on
the
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
daily cron regressions emails, and especially since the
do-regression
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
script isn't available in gem5. At a minimum, we should update
scons
Post by Mitch Hayenga
Post by Joel Hestness
or
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
do-regression on Zizzer to print all regression test names daily. Another
good thing to do is to include do-regression in gem5, so all contributors
can see how regressions are run. If we decide not to run full regressions
daily, those that are not run (but need to be as part of a "full
regression") should be marked with something more descriptive than
"skipped" like the currently tracing regressions (eio, tgen).
2) ::Expanding on my prior email:: If we formalize "full
regressions"
Post by Joel Hestness
to
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
include all tests, then we *really* need to include full,
out-of-the-box
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
runable regressions within the gem5 repo or at least using nicely
packaged
binaries/disks in a tar file (NOTE: even the FS files tarball
requires
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
modifying configs/common/SysPaths.py so the simulator can find the
files).
It should be possible for both committers AND patch contributors
to
Post by Mitch Hayenga
Post by Joel Hestness
run
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
the
full regression suite (not just those committers with access to
Zizzer).
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Otherwise, it seems like an unreasonable expectation for
committers
Post by Mitch Hayenga
Post by Joel Hestness
with
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
access to Zizzer to completely manage regression test updates.
Probably also makes sense to firm up and document
committer/Zizzer
Post by Mitch Hayenga
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
access
and regression plans while I go through as a partial guinea pig.
Joel
On 27/08/2015 14:34, "gem5-dev on behalf of Joel Hestness"
Post by Andreas Hansson
Hi Andreas,
Post by Joel Hestness
Yes, I agree that committers should run full regressions (i.e.
all
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
quick
Post by Joel Hestness
tests that are verified daily on Zizzer, right?). I ran quick
regressions
Post by Joel Hestness
that are configured correctly, and they pass with this patch.
The problem with running all quick regressions currently is
that
Post by Mitch Hayenga
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
many
Post by Joel Hestness
tests don't run out-of-the-box, and I haven't found instructions
on
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
how to
Post by Joel Hestness
set up tests like the cpu2000 and FS tests. I made a request for
such
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
I'm totally willing to run all the quick regressions and
update
Post by Mitch Hayenga
as
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
appropriate, but I'd like more information on these. How does
one
Post by Mitch Hayenga
Post by Joel Hestness
set
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
up
Post by Joel Hestness
FS
and cpu2000 tests? Can we include Linux binaries in the tests/
directory
Post by Joel Hestness
so
those tests can run out-of-the-box? Can we change the cpu2000
tests
Post by Joel Hestness
to
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
some
other benchmarks without distribution restrictions, so they too
can
Post by Joel Hestness
be
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
included in tests/?
Thanks,
Joel
On Thu, Aug 27, 2015 at 7:19 AM, Andreas Hansson
Hi Joel,
Post by Andreas Hansson
It seems the patch from Emilio changes a few of the full system
regressions. I merely wanted to check if you simply forgot to
push
Post by Joel Hestness
a
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
stats
update?
In general I would expect anyone pushing patches to do a full
regression
run (and sanity check any changes). Agreed?
Post by Andreas Hansson
Thanks,
Andreas
-- IMPORTANT NOTICE: The contents of this email and any
attachments
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
are
confidential and may also be privileged. If you are not the
intended
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
recipient, please notify the sender immediately and do not
disclose
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
the
contents to any other person, use it for any purpose, or store
or
Post by Mitch Hayenga
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
copy
the
Post by Andreas Hansson
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ,
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road,
Cambridge
Post by Mitch Hayenga
Post by Joel Hestness
CB1
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any
attachments
Post by Mitch Hayenga
Post by Joel Hestness
are
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
confidential and may also be privileged. If you are not the
intended
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
recipient, please notify the sender immediately and do not
disclose
Post by Mitch Hayenga
Post by Joel Hestness
the
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
contents to any other person, use it for any purpose, or store or
copy
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ,
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge
CB1
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Post by Joel Hestness
Post by Andreas Hansson
9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments
are
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
confidential and may also be privileged. If you are not the
intended
Post by Mitch Hayenga
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
recipient, please notify the sender immediately and do not disclose
the
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
contents to any other person, use it for any purpose, or store or
copy
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ,
Post by Mitch Hayenga
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge
CB1
Post by Mitch Hayenga
Post by Joel Hestness
9NJ,
Post by ecastill
Post by Andreas Hansson
Post by Andreas Hansson
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments
are
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose
the
Post by Joel Hestness
Post by ecastill
Post by Andreas Hansson
contents to any other person, use it for any purpose, or store or
copy
Post by Mitch Hayenga
Post by Joel Hestness
the
Post by ecastill
Post by Andreas Hansson
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ,
Post by ecastill
Post by Andreas Hansson
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
WARNING / LEGAL TEXT: This message is intended only for the use of
the
Post by Mitch Hayenga
Post by Joel Hestness
Post by ecastill
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.
http://www.bsc.es/disclaimer
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
Loading...