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 >> > >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
