- What convinces you that physical.cc is used/accessed in Ruby? Some output? The config.ini file?
- My understanding is classic uses the physical memory model and Ruby uses the memory controller.cc. How that controller serializes accesses is based on the coherence protocol. But, if you want to sanity check what's going on and if both are being used, why not insert some "std:cout <<" in the code and run a hello world program with and without Ruby? Or just run for a maximum instruction of say 10 "--maxinsts=10" and follow what happens either using your "std::cout <<" statements or using gem5 traceflags "--debug-flag=X --debug-start=X". Or even better, put a GDB breakpoint at the line of code that is being called in physical.cc while using Ruby and then once it breaks, do a backtrace to see where it's being called from. On Mon, Dec 5, 2011 at 8:26 AM, Heiner Litz < [email protected]> wrote: > Hi Korey, > > as far as I can tell physical is even used in Ruby. At least > physicall.cc is still accessed in the case I enable Ruby. > MemoryController.cc is in fact only accessed if Ruby is enabled. Thats > why I am confused which components are used in which memory model. > Your link could not clear this up for me. As I understand it memcopies > the the simulated memory transactions to actual physical memory of the > machine that executes the simulation. It also serializes the main > memory on taking a snapshot. Please let me know if this is not the > case. > > thanks, Heiner > > On Thu, Dec 1, 2011 at 2:35 PM, Korey Sewell <[email protected]> wrote: > > If you are using Ruby, I dont think physical.cc is used. > > > > General information would be found here: > > http://gem5.org/Coherence-Protocol-Independent_Memory_Components. > > > > > > On Thu, Dec 1, 2011 at 6:48 AM, Heiner Litz > > <[email protected]> wrote: > >> > >> Hi Steve, > >> > >> thanks for your mail. I am running blackscholes from Parsec. I found > >> out that when starting the simulator with the classic memory model it > >> indeed works and I receive --cacheline_size sized transactions. When I > >> use ruby I receive only 32 and 64 bit write/read accesses. In both > >> cases I have caches enabled (--caches --l2cache --cacheline_size=64). > >> > >> Could you clarify the behavior of physical.cc within the Ruby memory > >> system? > >> > >> How does it interact with MemoryControll.cc ? > >> > >> In the case of Ruby, how is the latency calculated as there are > >> statements within MemoryControll.cc as well as in physical.cc? > >> > >> thanks a lot, Heiner > >> > >> > >> On Wed, Nov 30, 2011 at 10:43 PM, Steve Reinhardt <[email protected]> > >> wrote: > >> > Hi Heiner, > >> > What workload are you running, and what configuration are you using? > >> > You're > >> > right that you should be seeing cache-block-size accesses if you have > a > >> > cache in your system. > >> > Steve > >> > > >> > On Wed, Nov 30, 2011 at 1:19 PM, Heiner Litz < > [email protected]> > >> > wrote: > >> >> > >> >> Hi, > >> >> > >> >> I am analyzing the memory traffic within physical.cc and the size of > >> >> the accesses is always 8/32/64 bit. Shouldn't all the accesses have > >> >> the size of the system's cache line size? > >> >> > >> >> Why (and where) is a cache line writeback of dirty data from L2 > broken > >> >> down into 32/64 bit accesses that are seen in physical.cc? > >> >> > >> >> thanks, Heiner > >> >> _______________________________________________ > >> >> gem5-users mailing list > >> >> [email protected] > >> >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > >> > > >> > > >> > _______________________________________________ > >> > gem5-users mailing list > >> > [email protected] > >> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > >> > > >> _______________________________________________ > >> gem5-users mailing list > >> [email protected] > >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > > > > > > > -- > > - Korey > > > > _______________________________________________ > > gem5-users mailing list > > [email protected] > > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > -- - Korey
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
