Hi Ali, I did understand the flow from other caches to L1 and why the data needs to be kept consistent. But I am asking about the case when the response is from L1 to CPU. It seems (from my previously mentioned example) that when there is a store hit, the data that is being sent from L1 to CPU is of 8 bytes and when a miss occurs, it is of 64 bytes. What you send to the CPU, should it not be independent of cache? Is the CPU making use of the data that is sent from Cache in case of store request? Thank you once again for your time.
On Mon, Jun 17, 2013 at 1:30 AM, Ali Saidi <sa...@umich.edu> wrote: > Remember that the cache much coherently update the line. The request in 8 > bytes, but line is likely 64 bytes. In the case of a miss the cache that is > handling the write (L1) must get the entire line and replace the 8 bytes, > otherwise any other data in the line would be incorrect. In the case of a > hit the data is written into the line, in the case of a miss the line is > requested from another cache or the memory system with exclusive access > permission and then the write completes. > > Thanks, > Ali > > > On Jun 16, 2013, at 12:15 PM, biswabandan panda <biswa....@gmail.com> > wrote: > > Hi Ali, > > I have been trying to track store requests and responses between > processor and cache. > There is a case > When there is a write hit, the response from dcache to processor is > writeResp with size 8 and no new data is copied into the packet. > If write miss, the response from dcache to procesor is readExResp with > size 32 (assuming block size is 32) and data which is got by filling the > cache. > > Example: > ------When c5fc0 misses (block_aligned of c5fd0) > 872000: system.cpu0.dcache: WriteReq c5fd0 miss > 873000: system.cpu0.dcache: getTimingPacket WriteReq for address c5fd0 > size 8 > 873000: system.cpu0.dcache: getBusPacket created ReadExReq address c5fc0 > size 32 > 914000: system.cpu0.dcache: ReadExResp addr: c5fc0 data : 0 size 32 > ------When c5fc0 hits > 1016000: system.cpu0.dcache: access for WriteReq address c5fc0 size 8 > 1016000: system.cpu0.dcache: WriteReq c5fc0 hit state: f (M) valid: 1 > writable: 1 readable: 1 dirty: 1 tag: 31 data: 0 > 1016000: system.cpu0.dcache: WriteResp addr: c5fc0 data : ac size 8 > > Will it not affect the execution path? When there is a miss, the data that > is sent is different from when there is a hit in the cache -- should it not > depend on cache? > > > > On Sat, Jun 15, 2013 at 9:33 PM, Ali Saidi <sa...@umich.edu> wrote: > >> Are you looking at a request or a response. The request very well could >> not have any data associated with it, but the response will. >> >> Ali >> >> On Jun 14, 2013, at 1:00 AM, biswabandan panda <biswa....@gmail.com> >> wrote: >> >> Hi, >> In an unmodified copy of gem5, I made the data in packet.hh as >> public and tried to print it in schedSendTiming. It shows 0 as value for >> all the packets when I print it using (int)*(pkt->data). >> Is the data that is fetched from cache being sent to cpu? If yes how do I >> track(print) it? >> Thank you once again for your time. >> >> >> On Fri, Jun 14, 2013 at 11:14 AM, Ali Saidi <sa...@umich.edu> wrote: >> >>> Actual data is stored in the caches. >>> >>> Ali >>> >>> On Jun 13, 2013, at 11:49 PM, biswabandan panda <biswa....@gmail.com> >>> wrote: >>> >>> >>> Hi, >>> I have modified the access function in cache to service a miss as hit >>> even when a particular block is not found. (This is just to collect some >>> statistics). I initially had assumed that gem5 does not store actual data >>> in cache and hence if a request misses at L1, if I just do "insertBlock, >>> memcpy and satisfyCpuSideRequest" and return true so that recvTimingReq >>> follows hit path, there ll be no error except that my simulation results >>> (ipc, misses, hits etc) will not be correct. >>> But when I run the same, I get this error >>> panic: fault (unalign) detected @ PC (0x120046574=>0x120046578) >>> When I googled for this error in one of the replies it says PC value is >>> corrupted. If gem5 did not store any data in cache, I by my code would have >>> modified only the timing parameter. How did this happen? If gem5 stores >>> actual data, how do I print it? >>> I also get this error for few other benchmarks >>> panic: Tried to access unmapped address 0x8. >>> >>> >>> Any pointers would be of great help. >>> >>> -- >>> >>> *thanks®ards >>> * >>> *BISWABANDAN* >>> http://www.cse.iitm.ac.in/~biswa/ >>> >>> “We might fall down, but we will never lay down. We might not be the >>> best, but we will beat the best! We might not be at the top, but we will >>> rise.” >>> >>> >>> _______________________________________________ >>> gem5-users mailing list >>> gem5-users@gem5.org >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >>> >>> >>> _______________________________________________ >>> gem5-users mailing list >>> gem5-users@gem5.org >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> >> >> >> -- >> >> *thanks®ards >> * >> *BISWABANDAN* >> http://www.cse.iitm.ac.in/~biswa/ >> >> “We might fall down, but we will never lay down. We might not be the >> best, but we will beat the best! We might not be at the top, but we will >> rise.” >> >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > > -- > > *thanks®ards > * > *BISWABANDAN* > http://www.cse.iitm.ac.in/~biswa/ > > “We might fall down, but we will never lay down. We might not be the best, > but we will beat the best! We might not be at the top, but we will rise.” > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > -- *thanks®ards * *BISWABANDAN* http://www.cse.iitm.ac.in/~biswa/ “We might fall down, but we will never lay down. We might not be the best, but we will beat the best! We might not be at the top, but we will rise.”
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
