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 On Fri, Aug 28, 2015 at 2:59 AM, ecastill <[email protected]> wrote: > 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 > > > On 28/08/15 09:27, Andreas Hansson wrote: > >> 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" >> <[email protected] on behalf of [email protected]> wrote: >> >> 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" >>> <[email protected] on behalf of [email protected]> wrote: >>> >>> 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? >>>> >>>> >>>> >>>> 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" >>>> >>>>> <[email protected] on behalf of [email protected]> wrote: >>>>> >>>>> 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/[email protected]/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 >>>>>> >>>>>> On Thu, Aug 27, 2015 at 7:19 AM, Andreas Hansson >>>>>> >>>>> <[email protected] >>>>> >>>>>> wrote: >>>>>> >>>>>> 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 >>>>>>> [email protected] >>>>>>> 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 >>>>>> [email protected] >>>>>> 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 >>>>> [email protected] >>>>> 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 >>>> [email protected] >>>> 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 >>> [email protected] >>> 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
