Hi all, Korey, yes I put in cout statements in physical.cc which is why I came to the conclusion that physical is still used in Ruby. Stephens and Nilays comments make sense however lead to the following question:
Both MemoryController and physical calculate the latency of a memory access. If Stephen and Nilay is correct I assume that the latency provided by physical should just get ignored. My tests however revealed the opposite, but I will recheck. thanks, Heiner On Mon, Dec 5, 2011 at 8:50 PM, Steve Reinhardt <[email protected]> wrote: > 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 _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
