Sorry for dropping out on this... I had a last-minute trip come up and it fell through the cracks.
My guess would be that Ruby is handling the coherence, so that's where all the block-level transfers are happening, and then physical.cc is just being used as a functional data store. Thus once all the coherence interactions in Ruby occur, a single small access is done to PhysicalMemory just to get the actual data value. I'm pretty sure that's how it originally worked. I thought Ruby had evolved to the point where it was providing data, but maybe that's not quite there yet, or needs to be enabled separately. Nilay or Brad could probably provide more insight on this point. Steve On Mon, Dec 5, 2011 at 11:16 AM, Korey Sewell <[email protected]> wrote: > - 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 >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
