Hi Shuai, - Q1) I believe schedTimingResp at line 1454 in cache.cc handles a cache miss not hit. - Q2) I'm not sure if I understand your question. Your figure and description of how cache is looked up seem fine to me. Hit or Miss happens for every access. So I think you would say they are defined for cache lines, If I want to use your terminology. If the cache line that contains the data is present in cache, then that access is a hit, otherwise it is a miss. - Q3) I haven't dumped any cache data in full-system mode, but I expect it to be similar to system-emulation mode. These two functions are triggered when you use any of the timing CPU modes (timing, minor, detailed). You need to specify that using "--cpu-type".
Good luck, Majid On Wed, Jan 4, 2017 at 7: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 >>>> >>> >>> >> > > _______________________________________________ > 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
