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