Hi Shuai, By default, se/fs.py use the atomic CPU, which performs atomic memory accesses. This CPU/memory mode is used to fast-forward the simulation, and does not accurately perform timing operations. All of the memory requests/responses flow through the "atomic" functions (recvAtomic). You should specify the CPU type on the command line to use timing mode (e.g., --cpu-type=timing or --cpu-type=detailed).
Cheers, Jason On Wed, Jan 4, 2017 at 9:52 AM Shuai Wang <[email protected]> wrote: > Sorry, what I mean is function "recvTimingReq", not function " > schedTimingResp"... > > On Wed, Jan 4, 2017 at 10:23 AM, Shuai Wang <[email protected]> > wrote: > > Besides, while my instrumented code in the "schedTimingResp" function > works well when leveraging the system call mode, I find the "schedTimingResp" > function is never executed in the full-system simulation mode. Am I missed > anything here? > > This is the command I use: > > ./build/X86/gem5.opt --debug-flags=CacheDebug > --debug-file=cacheDebug.out.gz configs/example/fs.py > --disk-image=/home/test/work/x86_full_system/disks/linux-x86.img > --kernel=/home/test/work/x86_full_system/binaries/x86_64-vmlinux-3.2.1 > --caches > > By inserting some printf at the beginning of function "schedTimingResp ", I > am pretty sure this function is never invoked... > > On Tue, Jan 3, 2017 at 11:13 PM, Shuai Wang <[email protected]> > wrote: > > Hi Majid, > > Thank you so much for your detailed information. I strongly appreciate > that. > > I tried to update the code as you said, and it works fine to dump the > information in the C++ code. However, I am still confused to interpret the > "cache state" information at this step. Could you please take a look at the > following questions and shed some lights on it? Thank you! > > The first question is that I can never observe a "cache miss": > > So what I am basically doing right now, as you suggested, is to check the > conditions in the context of each "cpuSidePort->schedTimingResp" to > decide whether the current memory addressing leads to a hit or miss. > However, after running multiple test cases (including some small binaries > and mediam size GNU Coreutils binaries), all I can find is the "hit" > (schedTimingResp > at line 742 of the cache.cc) and schedTimingResp at line 1454 of the > cache.cc. Basically I cannot find any "miss" (schedTimingResp at line 801 > of the cache.cc). Am I missed anything here? > > The second question is still about the interpretation of the cache state: > > If I understood correctly, given a N-bit memory address, it is dissected > into the following three parts in a memory access: > > [image: Inline image 2] > > The "set index" is used to locate the cache set in which the data may be > stored, and the tag is used to confirm that the data currently indeed > presents in one of the cache lines in that cache set. In other words, I > understand that the "cache state" (hit; miss; etc.) should be associated > with each cache set regarding every memory addressing. > > Given the above context, I would like to confirm that the captured > "hit/miss" surely represents the cache state of the accessed cache set. Or > it is actually something towards the cache lines? > > Am I clear on this? Any suggestion and advice would be appreciated! Thank > you! > Sincerely, > Shuai > > > > On Tue, Jan 3, 2017 at 3:12 PM, Majid Namaki Shoushtari <[email protected]> > wrote: > > Hi Shuai, > > I don't think Jason meant that you need to add a function to Caches.py. > You will need to add something to the C++ class (src/mem/cache/cache.hh/cc). > > I'm not sure what kind of information you need to dump, but basically all > of the incoming requests from CPU are received here: > "Cache::CpuSidePort::recvTimingReq(PacketPtr pkt)" > and all of the responses to CPU are happening anywhere there is a call to: > "cpuSidePort->schedTimingResp". There is currently four places that > responses to CPU are scheduled. If you read the code, it's relatively easy > to figure out which call site covers what condition (hit, miss, uncacheable > access, etc). > > If you need to dump this information for one (some) specific cache(s) > only, one way of doing it is to pass a boolean variable and make it > conditional based on the value of that variable. For that you will need to > add the variable to Caches.py and possibly CacheConfig.py. > > Cheers, > Majid > > > On Tue, Jan 3, 2017 at 8:21 AM, Shuai Wang <[email protected]> wrote: > > Dear Jason, > > Thank you so much for your reply. Could you please elaborate more on how > to "implement a function in Caches.py to dump the data"? As far as I can > see, there are only some cache parameters defined in this scripts.. I > really have no idea how should I bridge the code there with the runtime > cache state (my focus is the L1 D Cache)... > > I am not a system person and I am sincerely sorry if it is actually quite > obvious... Thank you so much in advance! > > Sincerely, > Shuai > > On Mon, Jan 2, 2017 at 11:01 AM, Jason Lowe-Power <[email protected]> > wrote: > > Hi Shuai, > > There is currently nothing built into gem5 to dump the cache state (unless > you're using Ruby in which case you can look at the code to take a > checkpoint in the RubySystem class and the CacheTrace class). However, it > should be pretty simple to dump the data in the classic caches. You would > need to get a pointer to all of the caches, then add a function to the > Cache class that dumps the data. You may be able to leverage the DDUMP > macro which formats data in a reasonable way. Or, if you're only going to > be using code to consume the output, you can look into the protobuf support > in gem5 for dumping/consuming data. > > Cheers, > Jason > > On Thu, Dec 29, 2016 at 10:38 PM Shuai Wang <[email protected]> > wrote: > > Dear list, > > > I am using the full-system simulation of gem5 to analyze the cache access > of some x86 binary code. I have been able to add a monitor between the CPU > and the L1 data cache to track all the cache access when executing the > binary code on the simulated OS. > > Currently, I am thinking to go one step further and dump the cache state > during the execution of the binary code. After a quick search online, I am > unable to find some useful information, and I am wondering if it is > actually possible to do so..? > > Could anyone provide some pointers regarding this task? Thank you in > advance! > > Sincerely, > Shuai > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > -- > > Jason > > _______________________________________________ > 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 > > > > > -- > Majid Namaki Shoushtari > PhD Candidate > Department of Computer Science > University of California, Irvine > Irvine, CA 92697 > [email protected] > http://www.ics.uci.edu/~anamakis > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > > -- Jason
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
