Hi Andreas, Yes I am running with out of order core. I looked at the demand_mshr stats and they pretty much follow the same trend... On Jul 27, 2015 2:41 AM, "Andreas Hansson" <andreas.hans...@arm.com> wrote:
> Hi Nimish, > > Double check the stats. If I remember correctly, “demand_mshr_miss_rate”, > may be what you are looking for. The stat you list may be misleading due to > several accesses to the same line (are you running with the out-of-order > core?). > > Andreas > > From: gem5-users <gem5-users-boun...@gem5.org> on behalf of Nimish > Girdhar <nimi...@tamu.edu> > Reply-To: gem5 users mailing list <gem5-users@gem5.org> > Date: Friday, 17 July 2015 18:28 > To: gem5 users mailing list <gem5-users@gem5.org> > Subject: Re: [gem5-users] Why cache misses are decreasing when core > frequency increase? > > Thanks for replying Andreas, Yes I am running the same workload with > same instructions. > > Below are the stats that I got:- > > > 2Ghz > > > 4Ghz > > sim_seconds > > 3.464073 > > > 1.73349 > > sim_insts > > 38015556363 > > > 37585527017 > > system.cpu0.icache.demand_miss_rate::total > > 0.00057 > > > 0.000382 > > system.cpu0.icache.demand_misses::total > > 2160668 > > > 1435056 > > system.cpu0.dcache.demand_miss_rate::total > > 0.009694 > > > 0.00833 > > system.cpu0.dcache.demand_misses::total > > 10080210 > > > 8412882 > > I am seeing a similar pattern in all cpu's cache stats. > > Yes I am doing a hackish DVFS where I am changing clock speed behind the > back of the OS. From my research project point of view, I am just concerned > with the simulation times as I am doing different experiments and just the > simulation time matters for me. But I still want to reason the cache > behavior, as long as I am able to do that, I should be okay. That's why I > need some help with the reasoning as to why I am seeing the above stats? > > Any thoughts? > > Thanks, > > > On Thu, Jul 16, 2015 at 3:06 PM, Andreas Hansson <andreas.hans...@arm.com> > wrote: > >> Hi Nimish, >> >> How do you determine cache misses (what stat are you looking at)? Are >> you running the same workload in the two scenarios (i.e. are the actual >> instructions executed the same)? Is it full system (and if so, are you >> changing the core frequency without the OS knowing about it)? >> >> Can you shed some more light on your experiment? Overall I’d say it’s a >> bad idea to be changing clocks behind the OS’s back... >> >> Andreas >> >> From: gem5-users <gem5-users-boun...@gem5.org> on behalf of Nimish >> Girdhar <nimi...@tamu.edu> >> Reply-To: gem5 users mailing list <gem5-users@gem5.org> >> Date: Thursday, 16 July 2015 23:00 >> To: gem5 users mailing list <gem5-users@gem5.org> >> Cc: Gaurav Sharma <gaurav1...@gmail.com> >> Subject: Re: [gem5-users] Why cache misses are decreasing when core >> frequency increase? >> >> Anybody has any idea what might be happening here?? >> Any help will be appreciated.. >> Thanks, >> On Jul 14, 2015 9:38 AM, "Nimish Girdhar" <nimi...@tamu.edu> wrote: >> >>> Hello, >>> >>> I am trying to use DVFS for my project. But I want the frequency >>> control in hardware so I cannot use the DVFS support given by Gem5 as that >>> is on kernel level. For my project I added each core and their l1 caches to >>> a different clock domains and hacked the code to change the frequency of >>> the domains whenever I wanted. >>> >>> To check if it is working I fired two runs, one with default frequency >>> settings (which is 2 Ghz) and in the other run I double the frequency of >>> each domain, so each core runs on 4Ghz. >>> >>> Now looking at the stats, I see simulation time dropping to almost >>> half which is expected. But I am not able to reason the cache stats. I am >>> seeing the cache misses for all caches also decreasing by almost half. Can >>> anybody reason how is that happening? >>> >>> I am running arm Full system with classic memory model. All memory >>> settings are default. >>> >>> Thanks, >>> -- >>> Warm regards >>> Nimish Girdhar >>> Department of Electrical and Computer Engineering >>> Texas A&M University >>> >> >> -- 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 >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > > -- > Warm regards > Nimish Girdhar > Department of Electrical and Computer Engineering > Texas A&M University > > -- 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 > 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
