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