Hello Andreas, I made changes to the source code to fix android disk name search and ran quick regression tests, and they passed. I also ran long regressions to just make sure that nothing is broken. I observed two "changed" tests. So, I went back and ran long regressions on fresh gem5 repo, and still ended up with two similar "changed" test cases:
*Changed:* *1)* system.cpu0.iew.predictedTakenIncorrect 287589 287591 2 +0.00% system.cpu0.iew.branchMispredicts 683109 683111 2 +0.00% ***** build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview-o3-dual CHANGED! *2)* system.physmem_0.actBackEnergy 68919855390 68915344410 -4510980 -0.01% system.physmem_0.totalEnergy 1860855224610 1860850713630 -4510980 -0.00% system.physmem_0.averagePower 667.510956 667.510917 -0.000039 -0.00% ***** build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview-switcheroo-full CHANGED! *Errors:* Maximum error magnitude: +0.000695% Maximum error magnitude: +0.006545% For both test cases, there is no change in key statistics. Is this error considered small and can be ignored? Or, you have successful regressions for long as well with no errors on recent gem5-dev repo (If so, I will consider debugging it further)? Thank you for all your help so far. Best, -Rizwana On Thu, Feb 5, 2015 at 3:46 AM, Andreas Hansson <[email protected]> wrote: > Hi Rizwana, > > Looks good to me. Could you post a patch on RB? > > Thanks, > > Andreas > > From: Rizwana Begum <[email protected]> > Date: Wednesday, 4 February 2015 22:57 > > To: Andreas Hansson <[email protected]> > Cc: gem5 users mailing list <[email protected]> > Subject: Re: [gem5-users] DRAMCtrl auto precharge logic simplification > > Hello Andreas, > > Sure. However, the warning will not be printed if I unset M5_PATH and > change SysPaths.py to point to system files. > I think FSConfig.py can be modified to look for 'android' only in image > name instead of full path, changing it from > > if mdesc.disk().lower().count('android'): > cmdline += " init=/init " > > to > > if (os.path.split(mdesc.disk())[-1]).lower().count('android'): > cmdline += " init=/init " > > Thanks, > -Rizwana > > On Wed, Feb 4, 2015 at 4:26 PM, Andreas Hansson <[email protected]> > wrote: > >> Hi Rizwana, >> >> Ouch. Is there anyway we could warn for this? Perhaps just warn if >> android is in the M5_PATH rather than the disk image name? >> >> Andreas >> >> From: Rizwana Begum <[email protected]> >> Date: Wednesday, 4 February 2015 20:59 >> >> To: Andreas Hansson <[email protected]> >> Cc: gem5 users mailing list <[email protected]> >> Subject: Re: [gem5-users] DRAMCtrl auto precharge logic simplification >> >> Hello Andreas, >> >> I finally have successful regressions. Sigh! >> >> my M5_PATH had 'android' key word in it >> (/home/rizwana/gem5-android/gem5/system/), and because of that 'init=/init' >> was appended to boot_osflags in FSConfig.py. That resulted in more >> instructions and caused mismatch in stats. I just renamed my working >> directory to not have 'android' in path and regressions passed. >> >> Thank you, >> -Rizwana >> >> On Wed, Feb 4, 2015 at 9:32 AM, Rizwana Begum <[email protected]> >> wrote: >> >>> Hello Andreas, >>> >>> Okay. Yes, I think problem is somewhere on my end. One of my >>> colleagues ran the regression tests, and they passed for him too. The only >>> difference is that my tests were on *changeset: 10667:e17949745150 *(tip >>> as of yesterday)*, *and he ran tests on latest *changeset: >>> 10680:7639c17357dc *(current tip) . I am running tests now on that to >>> see if that makes any difference (I am doubtful as I believe all gem5 >>> commits should pass the regression tests, but there is nothing else that >>> pops out at me.). >>> >>> Thank you, >>> -Rizwana >>> >>> On Wed, Feb 4, 2015 at 8:48 AM, Andreas Hansson <[email protected] >>> > wrote: >>> >>>> Hi Rizwana, >>>> >>>> I created a minty fresh VM with Ubuntu 14.04 and the ARM regressions >>>> pass just fine both with gcc and clang. >>>> >>>> Andreas >>>> >>>> From: Andreas Hansson <[email protected]> >>>> Date: Wednesday, 4 February 2015 08:52 >>>> To: Rizwana Begum <[email protected]> >>>> >>>> Cc: gem5 users mailing list <[email protected]> >>>> Subject: Re: [gem5-users] DRAMCtrl auto precharge logic simplification >>>> >>>> Hi Rizwana, >>>> >>>> The regressions run fine on a rather large selection of hosts and >>>> compilers (OS X, RHE5, RHE6, Ubuntu 10.04, Ubuntu 12.04, with gcc 4.6 all >>>> the way to 4.9, and clang 3.1). I cannot imagine Ubuntu 14.04 should cause >>>> problems. The thing that makes me most suspicious is that you get different >>>> results when re-running the same tests. There is no non-determinism in the >>>> simulator, and the results should be the same every time. We have done >>>> quite a lot of “linting” and an ARM regression run with UBSan switched on >>>> shows no run-time errors at all. >>>> >>>> Is anyone else having these issues? >>>> >>>> Andreas >>>> >>>> From: Rizwana Begum <[email protected]> >>>> Date: Wednesday, 4 February 2015 05:23 >>>> To: Andreas Hansson <[email protected]> >>>> Cc: gem5 users mailing list <[email protected]> >>>> Subject: Re: [gem5-users] DRAMCtrl auto precharge logic simplification >>>> >>>> Hello Andreas, >>>> >>>> This is really strange. I cloned the repo and downloaded the system >>>> files again. The errors still don't go away. I tried for 'fast' binary as >>>> well and the errors persist. I am trying it all on Ubuntu 14.04. What host >>>> OS do you use? I also noticed that number of these errors vary from run to >>>> run. I am planning to run long ones tonight, will let you know if those run >>>> fine or result in errors. >>>> >>>> Thank you, >>>> -Rizwana >>>> >>>> On Tue, Feb 3, 2015 at 4:56 PM, Andreas Hansson < >>>> [email protected]> wrote: >>>> >>>>> Hi Rizwana, >>>>> >>>>> That is strange. I just cloned the repo and ran with the files from >>>>> http://www.gem5.org/dist/current/arm/aarch-system-2014-10.tar.xz without >>>>> any problems. >>>>> >>>>> Could you do a clean build and re-download just to be sure? >>>>> >>>>> Andreas >>>>> >>>>> From: Rizwana Begum <[email protected]> >>>>> Date: Tuesday, 3 February 2015 21:49 >>>>> >>>>> To: Andreas Hansson <[email protected]> >>>>> Cc: gem5 users mailing list <[email protected]> >>>>> Subject: Re: [gem5-users] DRAMCtrl auto precharge logic simplification >>>>> >>>>> Hi Andreas, >>>>> >>>>> Here are the ones that changed: >>>>> >>>>> ***** >>>>> build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-atomic >>>>> CHANGED! >>>>> ***** >>>>> build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-atomic-dual >>>>> CHANGED! >>>>> ***** >>>>> build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-timing >>>>> CHANGED! >>>>> ***** >>>>> build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-timing-dual >>>>> CHANGED! >>>>> ***** >>>>> build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-switcheroo-atomic >>>>> CHANGED! >>>>> ***** >>>>> build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview64-simple-atomic >>>>> CHANGED! >>>>> ***** >>>>> build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview64-simple-atomic-dual >>>>> CHANGED! >>>>> ***** >>>>> build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview64-simple-timing >>>>> CHANGED! >>>>> ***** >>>>> build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview64-simple-timing-dual >>>>> CHANGED! >>>>> ***** >>>>> build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview64-switcheroo-atomic >>>>> CHANGED! >>>>> >>>>> Thank you, >>>>> -Rizwana >>>>> >>>>> On Tue, Feb 3, 2015 at 4:04 PM, Andreas Hansson < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Rizwana, >>>>>> >>>>>> That doesn’t sound good. Let me double check the system files. >>>>>> >>>>>> Which regressions are “changed"? >>>>>> >>>>>> Andreas >>>>>> >>>>>> From: Rizwana Begum <[email protected]> >>>>>> Date: Tuesday, 3 February 2015 21:01 >>>>>> >>>>>> To: Andreas Hansson <[email protected]> >>>>>> Cc: gem5 users mailing list <[email protected]> >>>>>> Subject: Re: [gem5-users] DRAMCtrl auto precharge logic >>>>>> simplification >>>>>> >>>>>> Hello Andreas, >>>>>> >>>>>> I ran the tests again and they result in similar errors (magnitude >>>>>> error %) in stats. When I don't specify the paths to system files, tests >>>>>> fail complaining about system files path. I ran tests on my local Ubuntu >>>>>> (14.04) as well as on a CentOS 5 server, both result in similar errors. >>>>>> Though none of the tests fail, I don't have clean regression tests (I >>>>>> only >>>>>> tried quick ones). I have following gem5 commit: >>>>>> >>>>>> *changeset: 10667:e17949745150* >>>>>> *tag: tip* >>>>>> *user: Malek Musleh <[email protected] >>>>>> <[email protected]>>* >>>>>> *date: Fri Jan 30 15:49:34 2015 -0600* >>>>>> *summary: config: arm: fix os_flags* >>>>>> >>>>>> All I did was cloned gem5-dev repository, compiled ARM opt binary >>>>>> (scons build/ARM/gem5.opt), downloaded system files, placed the binaries >>>>>> and disks folder in *system* folder, pointed to the *system* folder >>>>>> in SysPaths.py, and then ran quick regressions (scons >>>>>> build/ARM/tests/opt/quick). >>>>>> >>>>>> Any help to resolve this issue would be great. >>>>>> >>>>>> Thank you, >>>>>> -Rizwana >>>>>> >>>>>> On Tue, Feb 3, 2015 at 12:02 PM, Rizwana Begum <[email protected] >>>>>> > wrote: >>>>>> >>>>>>> Hello Andreas, >>>>>>> >>>>>>> I ran tests on clean repo (without any source code modifications), >>>>>>> however, I had modified SysPaths.py to point to binaries, disks >>>>>>> downloaded >>>>>>> from gem5 download page (ARM Full-System Files >>>>>>> <http://www.gem5.org/dist/current/arm/aarch-system-2014-10.tar.xz>). >>>>>>> I am not sure, if that caused the tests to use different kernel/disk >>>>>>> image >>>>>>> than the default ones. I compiled opt binary and ran quick tests on opt >>>>>>> (scons build/ARM/tests/opt/quick). >>>>>>> >>>>>>> I am running tests now without modifications to SysPaths.py. I >>>>>>> will let you know if my results would change. >>>>>>> >>>>>>> Thank you, >>>>>>> -Rizwana >>>>>>> >>>>>>> On Tue, Feb 3, 2015 at 11:04 AM, Andreas Hansson < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi Rizwana, >>>>>>>> >>>>>>>> There should be no stats changes at all on the trunk. The >>>>>>>> regression runs from yesterday confirms this as well. Are you sure you >>>>>>>> ran >>>>>>>> with a clean repo? >>>>>>>> >>>>>>>> Andreas >>>>>>>> >>>>>>>> From: Rizwana Begum <[email protected]> >>>>>>>> Date: Tuesday, 3 February 2015 15:44 >>>>>>>> To: Andreas Hansson <[email protected]> >>>>>>>> Cc: gem5 users mailing list <[email protected]> >>>>>>>> Subject: Re: [gem5-users] DRAMCtrl auto precharge logic >>>>>>>> simplification >>>>>>>> >>>>>>>> Hello Andreas, >>>>>>>> >>>>>>>> Yes, the condition will still consider bank conflicts for >>>>>>>> open-adaptive policy. >>>>>>>> >>>>>>>> I made the fix and ran quick regression tests for ARM. All of the >>>>>>>> tests passed, however there are some errors(in % difference) in >>>>>>>> results. >>>>>>>> Here is the output before and after the fix (grep for error): >>>>>>>> >>>>>>>> *gem5-dev tip (before fix):* >>>>>>>> Maximum error magnitude: +68.750000% >>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>> Maximum error magnitude: +89.743590% >>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>> Maximum error magnitude: +9999.000000% >>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>> Maximum error magnitude: +9999.000000% >>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>> Maximum error magnitude: +68.750000% >>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>> >>>>>>>> *With fix:* >>>>>>>> Maximum error magnitude: +6.666667% >>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>> Maximum error magnitude: +9999.000000% >>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>> Maximum error magnitude: +9999.000000% >>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>> Maximum error magnitude: +9999.000000% >>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>> Maximum error magnitude: +38.862333% >>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>> Maximum error magnitude: +68.750000% >>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>> Maximum error magnitude: +89.743590% >>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>> Maximum error magnitude: +9999.000000% >>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>> Maximum error magnitude: +9999.000000% >>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>> Maximum error magnitude: +68.750000% >>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>> >>>>>>>> Is this a concern? or can I ignore these errors? >>>>>>>> >>>>>>>> PS: Attached full output of quick regression tests. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> -Rizwana >>>>>>>> >>>>>>>> On Tue, Feb 3, 2015 at 3:57 AM, Andreas Hansson < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi Rizwana, >>>>>>>>> >>>>>>>>> I look forward to see the patch. >>>>>>>>> >>>>>>>>> Note that open-adaptive and closed-adaptive behave differently. >>>>>>>>> In the open case we only close if there is no hit, and there is a bank >>>>>>>>> conflict. For the closed one we close if there are no hits (ignoring >>>>>>>>> if >>>>>>>>> there are conflicts or not). If this is till captured then by all >>>>>>>>> means go >>>>>>>>> ahead and simplify the code. Perhaps add some more comments to make >>>>>>>>> this >>>>>>>>> more clear. >>>>>>>>> >>>>>>>>> Andreas >>>>>>>>> >>>>>>>>> From: Rizwana Begum via gem5-users <[email protected]> >>>>>>>>> Reply-To: Rizwana Begum <[email protected]>, gem5 users >>>>>>>>> mailing list <[email protected]> >>>>>>>>> Date: Tuesday, 3 February 2015 05:01 >>>>>>>>> To: gem5 users mailing list <[email protected]> >>>>>>>>> Subject: [gem5-users] DRAMCtrl auto precharge logic simplification >>>>>>>>> >>>>>>>>> Hello All, >>>>>>>>> >>>>>>>>> I think the if condition that's checking to find the right >>>>>>>>> condition for auto-precharge in doDRAMAccess() can be simplified >>>>>>>>> >>>>>>>>> Original : >>>>>>>>> while (!(got_more_hits && >>>>>>>>> (got_bank_conflict || pageMgmt == >>>>>>>>> Enums::close_adaptive)) && >>>>>>>>> p != queue.end()) { >>>>>>>>> >>>>>>>>> Simplified: >>>>>>>>> while (!got_more_hits && p != queue.end()) { >>>>>>>>> >>>>>>>>> The above simplification comes as both close-adaptive and >>>>>>>>> open-adaptive policies keep row open if a hit is found. Otherwise the >>>>>>>>> search for a hit continues until the end of the queue and during the >>>>>>>>> search >>>>>>>>> got_bank_conflict gets updated anyways. >>>>>>>>> >>>>>>>>> I am planning to put this simplification on reviewboard (along >>>>>>>>> with another bug fix that I have). I would appreciate it if anyone >>>>>>>>> using >>>>>>>>> DRAM controller has any comments regarding this simplification. >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> -Rizwana >>>>>>>>> >>>>>>>>> >>>>>>>>> -- 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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- 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 >>>>>> >>>>> >>>>> >>>>> -- 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 >>>>> >>>> >>>> >>>> -- 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 >>>> >>> >>> >> >> -- 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 >> > > > -- 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-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
