Here's a summary from running with the printfs showing the reads, writes
and receive timings reported by dram.cc for libquantum:
reads, writes, receive timings
ARM_FS 1486578, 115473, 1605225
ARM_SE 347210, 3002, 350213
FS/SE 4.28, 38.47, 4.58
-Andrew
On Tue, Mar 13, 2012 at 11:33 PM, Andrew Cebulski <af...@drexel.edu> wrote:
> I figured out how to run my benchmark in ARM_SE. First, I had to
> recompile my benchmark statically linked, since I run it dynamically linked
> in ARM_FS. I was able to run the statically linked libquantum in ARM_SE
> with gem5.opt without any errors, the same as your tests. I did look at
> the committed instruction count within the stats file for the ARM_SE run
> with the O3 CPU, and it does look accurate.
>
> Next, I added this new statically linked libquantum to my disk image to
> run in ARM_FS with gem5.opt. It failed with the same exact instcount error
> in base_dyn_inst_impl.hh as with my dynamically linked libquantum
> benchmark.
>
> So it would seem that the problem only occurs in FS, not SE.
>
> Now the question is how to go about fixing the issue preventing your
> integration of DramSim2 from working in ARM_FS... Any ideas?
>
> It looks like you have some debugging coded into your dram.cc, but
> commented out (printf statements). I'll add them back and compare their
> outputs between ARM_SE and ARM_FS. I might convert them to DPRINTFs too.
>
> Do you know how to setup one of your ARM_SE benchmarks to run in ARM_FS?
> It basically involves putting it into the Gem5 Ubuntu image (i.e. using
> util/gem5img.py), creating a rcS file, and adding it in Benchmarks.py.
> This way you can try to reproduce the error in your environment. That
> would be a good start.
>
> -Andrew
>
>
> On Tue, Mar 13, 2012 at 6:08 PM, Andrew Cebulski <af...@drexel.edu> wrote:
>
>> As far as I can tell, the source of the instruction count problem either
>> is restricted to FS (don't know if restricted to ARM), varies with
>> environment setup or is caused by the cross-compiled binary file. I'm
>> doubtful of the latter two since I've run with various benchmarks in
>> gem5.fast to completion, and they have been within 10% of the committed
>> instructions that the benchmarks have run on physical hardware (as measured
>> with valgrind...same binary files).
>>
>> At this point, it would be helpful to know if anyone else has run a
>> benchmark with your patch on ARM_FS (or other arch) successfully. Luckily,
>> you have made it very easy to test since it replaces the old DRAMMemory
>> object. Otherwise, I'll continue debugging this and emailing the list with
>> questions as I go.
>>
>> Is it possible for this assertion to only occur in ARM_FS, not ARM_SE,
>> with the same benchmarks? I require full-system, so I haven't tested
>> ARM_SE. If my benchmarks pass with ARM_SE in gem5.opt, that should narrow
>> the source of the problem down.
>>
>> Thanks,
>> Andrew
>>
>>
>> On Tue, Mar 13, 2012 at 4:30 PM, Rio Xiangyu Dong
>> <riosher...@gmail.com>wrote:
>>
>>> I use gem5.opt, and never see this error.****
>>>
>>> ** **
>>>
>>> *From:* gem5-users-boun...@gem5.org [mailto:gem5-users-boun...@gem5.org]
>>> *On Behalf Of *Andrew Cebulski
>>> *Sent:* Tuesday, March 13, 2012 12:12 PM
>>>
>>> *To:* gem5 users mailing list
>>> *Subject:* Re: [gem5-users] A Patch for DRAMsim2 Integration****
>>>
>>> ** **
>>>
>>> Did you ever get this error building gem5.debug on revision 8643?
>>>
>>> -----****
>>>
>>> ** **
>>>
>>> cc1plus: warnings being treated as errors
>>> In file included from build/dramsim2/SystemConfiguration.h:42:0,
>>> from build/dramsim2/MemorySystem.h:42,
>>> from build/ARM_FS/mem/dram.hh:42,
>>> from build/ARM_FS/mem/dram.cc:39:
>>> build/dramsim2/PrintMacros.h:49:0: error: "DEBUG" redefined
>>> <command-line>:0:0: note: this is the location of the previous definition
>>>
>>> -----
>>>
>>> The DramSim2 repo has the same file:
>>> https://github.com/dramninjasUMD/DRAMSim2/blob/master/PrintMacros.h ****
>>>
>>>
>>> The solutions seems to be adding "#undef DEBUG" right before it gets
>>> defined. I can't find where it's getting declared initially though...
>>> Doing a grep of the gem5 src and ext repo's for a DEBUG define come up
>>> empty. Commenting out all defines of DEBUG in PrintMacros.h still results
>>> in the redefine message...****
>>>
>>> ** **
>>>
>>> I have two versions of gcc readily available (4.5.0 and 4.5.3), and I
>>> get it on both.****
>>>
>>> ** **
>>>
>>> -Andrew****
>>>
>>> On Tue, Mar 13, 2012 at 1:56 PM, Andrew Cebulski <af...@drexel.edu>
>>> wrote:****
>>>
>>> Hi Xiangyu,****
>>>
>>> ** **
>>>
>>> I just started looking into this some more. So at first I thought
>>> it was due to updating to a more recent revision, but then I went back to
>>> revision 8643, added your patch, built and ran....and now get the error
>>> with it too (when running ARM_FS/gem5.opt). I"m testing now to see if an
>>> update to SWIG might have resulted in this error, maybe someone on the
>>> mailing list would know if that's possible. The difference is 1.3.40 vs.
>>> 2.0.3, both of which are supported according to the dependencies wiki page.
>>> ****
>>>
>>> ** **
>>>
>>> Just for completeness, here's the error from revision 8643:****
>>>
>>> build/ARM_FS/cpu/base_dyn_inst_impl.hh:149: void
>>> BaseDynInst<Impl>::initVars() [with Impl = O3CPUImpl]: Assertion
>>> `cpu->instcount <= 1500' failed. ****
>>>
>>> ** **
>>>
>>> I also removed all the changes I've added for my research from the
>>> test with revision 8643 and your patch, aside from adding a new rcS file
>>> and the cross-compiled binary to the disk image for Libquantum (SPEC
>>> CPU2006). Note that I use CodeSourcery for cross-compiling.****
>>>
>>> ** **
>>>
>>> I have not tried running with gem5.debug, so I will be doing that
>>> today. Maybe this is an assertion that is occurring due to an
>>> optimization. That would mean it wouldn't be triggered in gem5.debug since
>>> it runs without optimizations. Have you tested all debug, opt and fast
>>> with your tests?****
>>>
>>> ** **
>>>
>>> Thanks,****
>>>
>>> Andrew****
>>>
>>> ** **
>>>
>>> On Tue, Mar 13, 2012 at 1:37 PM, Rio Xiangyu Dong <riosher...@gmail.com>
>>> wrote:****
>>>
>>> Hi Andrew,****
>>>
>>> ****
>>>
>>> I didn’t see this error in my simulations. May I ask which gem5 version
>>> you are using? I find some of the latest code updates do not comply with my
>>> changes. I am still using the DRAMsim2 patch on Gem5 repo8643, and have run
>>> all the runnable benchmarks in SPEC2006, SPEC2000, EEMBC2, and PARSEC2 on
>>> ARM_SE.****
>>>
>>> ****
>>>
>>> Thank you!****
>>>
>>> ****
>>>
>>> Best,****
>>>
>>> Xiangyu****
>>>
>>> ****
>>>
>>> *From:* Andrew Cebulski [mailto:af...@drexel.edu]
>>> *Sent:* Thursday, March 08, 2012 6:52 PM****
>>>
>>>
>>> *To:* gem5 users mailing list****
>>>
>>> *Cc:* riosher...@gmail.com; sa...@umich.edu****
>>>
>>>
>>> *Subject:* Re: [gem5-users] A Patch for DRAMsim2 Integration****
>>>
>>> ****
>>>
>>> Xiangyu,****
>>>
>>> ****
>>>
>>> I've been having an issue recently with the number of instructions
>>> I've been seeing committed to the CPU (I have a separate thread on this).
>>> It turns out the issue seems to be coming from this patch you created to
>>> integrate DramSim2 with Gem5. Unfortunately, I've been running with
>>> gem5.fast, not gem5.opt. So up until now, I haven't been seeing
>>> assertions. I thought I'd run it with gem5.opt or debug back in December,
>>> but I must not have. My runs on the Arm O3 cpu fails with this assertion:
>>> ****
>>>
>>> ****
>>>
>>> build/ARM/cpu/base_dyn_inst_impl.hh:149: void
>>> BaseDynInst<Impl>::initVars() [with Impl = O3CPUImpl]: Assertion
>>> `cpu->instcount <= 1500' failed.****
>>>
>>> ****
>>>
>>> Have you seen similar results? Is this count how many instructions
>>> are currently being processed by the cpu? My initial guess is that memory
>>> instructions being sent to DramSim2 are getting counted as committed
>>> regardless of whether they are mispredicted (and rerun). Any suggestions
>>> on where to insert DPRINTFs, or use current ones, to find out if this is
>>> what is happening?****
>>>
>>> ****
>>>
>>> Ali helped me earlier with getting the checker and some debug flags
>>> to track earlier. I currently have traces with debug flags Exec, ExecAsid
>>> and DynInst. I just need to know what to search for in them for useful
>>> info.****
>>>
>>> ****
>>>
>>> Thanks,****
>>>
>>> Andrew ****
>>>
>>> ****
>>>
>>> On Sun, Dec 18, 2011 at 5:04 PM, Dong, Xiangyu <riosher...@gmail.com>
>>> wrote:****
>>>
>>> Thanks. Actually I only tested it on ARM_SE and ARM_FS. Let me know if
>>> it also works for other processors.****
>>>
>>> ****
>>>
>>> In addition, I actually made more modification on the DRAMsim2 side.
>>> Maybe the most important one is that I changed the way how DRAMsim2 reports
>>> latency/bandwidth statistics. DRAMsim2 reports all the statistics after
>>> every EPOCH, and then resets all the numbers. For Gem5 users who are only
>>> interested in the statistics over the entire simulation time, you might
>>> want to change the codes in DRAMsim2/MemoryController.cpp and make similar
>>> changes like what I’ve done (that’s NOT in the patch since it’s more
>>> DRAMsim2-related).****
>>>
>>> ****
>>>
>>> Best,****
>>>
>>> Xiangyu****
>>>
>>> ****
>>>
>>> *From:* gem5-users-boun...@gem5.org [mailto:gem5-users-boun...@gem5.org]
>>> *On Behalf Of *Andrew Cebulski
>>> *Sent:* Sunday, December 18, 2011 6:38 AM
>>> *To:* gem5-users@gem5.org
>>> *Subject:* Re: [gem5-users] A Patch for DRAMsim2 Integration****
>>>
>>> ****
>>>
>>> Thanks for the integration patch Xiangyu! I'll let you know if I come
>>> across any bugs.****
>>>
>>> ****
>>>
>>> -Andrew****
>>>
>>> ****
>>>
>>> ****
>>>
>>> Date: Sun, 18 Dec 2011 01:48:58 -0800
>>> From: "Dong, Xiangyu" <riosher...@gmail.com>
>>> To: "gem5 users mailing list" <gem5-users@gem5.org>
>>> Subject: [gem5-users] A Patch for DRAMsim2 Integration
>>> Message-ID: <001201ccbd6a$45102210$cf306630$@gmail.com>
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>> Hi all,
>>>
>>>
>>>
>>> I have a Gem5+DRAMsim2 patch. I've tested it under both SE and FS modes.
>>> I'm willing to share it here.
>>>
>>>
>>>
>>> For those who have such needs, please go to my website
>>> www.cse.psu.edu/~xydong <http://www.cse.psu.edu/%7Exydong> to download
>>> the patch and test it. To enable
>>> DRAMSim2, use se_dramsim2.py script instead of se.py (for FS, you can
>>> create
>>> by yourself). The basic idea to enable the DRAMsim2 module is to use the
>>> derived DRAMMemory class instead of PhysicalMemory class.
>>>
>>>
>>>
>>> Please let me know if there are bugs.
>>>
>>>
>>>
>>> Thank you!
>>>
>>>
>>>
>>> Best,
>>>
>>> Xiangyu Dong
>>>
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL: <
>>> http://m5sim.org/cgi-bin/mailman/private/gem5-users/attachments/20111218/f3fdf5da/attachment.html
>>> >****
>>>
>>>
>>> _______________________________________________
>>> gem5-users mailing list
>>> gem5-users@gem5.org
>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users****
>>>
>>> ****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> _______________________________________________
>>> gem5-users mailing list
>>> gem5-users@gem5.org
>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>
>>
>>
>
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
