Thanks for the clarifcation on that Heiner. For the latency, check that there isnt a "directory_latency" of some sort set by the coherence protocol in Ruby. "configs/ruby/Ruby.py" and "configs/ruby/<protocol>.py"
should be the relevant files. On Mon, Dec 5, 2011 at 4:13 PM, Heiner Litz < [email protected]> wrote: > 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 > -- - Korey
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
