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 >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
