Hi keep in mind Marss cache does not store any data . so when a cache update happen we only change the line status without write any data to the lower level cache -Furat
On Wed, Nov 10, 2010 at 2:32 PM, Zhe Wang <[email protected]> wrote: > Hi, Avadh, > > Thank you for the reply. > > But for the code, > > if(queueEntry->request->get_type() == MEMORY_OP_UPDATE && wt_disabled_ == > false) { > >> if(type_ == L2_CACHE || type_ == L3_CACHE) { >> memdebug("L2/L3 cache update sending to >> lower\n"); >> queueEntry->eventFlags[ >> CACHE_WAIT_INTERCONNECT_EVENT]++; >> queueEntry->sendTo = lowerInterconnect_; >> >> memoryHierarchy_->add_event(&waitInterconnect_, >> 0, queueEntry); >> } >> >> } > > This is only for the write through cache, that is wt_disabled == false. > As you said in the previous email, Mass also implement a write back policy. > If using the write back policy, that is wt_disabled_ = true. I did not see > any place marss update the lower level cache line, when there is a memory > update request. Would you please explain this ? > > Since I am trying to use marss to do some experiment to see the effect of > write back memory, it is important for me to make clear about those > questions. Thank you. > > Best > zhe > > > 2010/11/10 avadh patel <[email protected]> > > On Tue, Nov 9, 2010 at 9:54 PM, Zhe Wang <[email protected]> wrote: >> > >> > Hi, Avadh, >> > >> > Thanks for your reply. I really appreciate it. >> > >> > I am still confused about that memory update operation when I look into >> the code in file CacheControler.cpp , >> > In line 713 in function >> > >> > bool CacheController::cache_access_cb(void *arg) >> > { >> > ...... >> > /* else its update and its a cache miss, so ignore that */ >> > else { >> > signal = &clearEntry_; >> > delay = cacheAccessLatency_; >> > queueEntry->eventFlags[CACHE_CLEAR_ENTRY_EVENT]++; >> > } >> > ......... >> > } >> > >> > I think the above code means if the memory operation is memory update >> operation and its a cache miss, then ignore the memory update operation. But >> from your explanation of the previous mail, if the operation type is memory >> update operation, the data should be write back to the next level cache, >> right? I am confused by this code. Would you please explain this ? >> Thanks. >> > >> >> The model we have implemented is like this: >> - When we receive an update request from upper level cache then we >> perform following actions: >> 1. Send the request to lower interconnect >> 2. Access cache and if its a hit then update its line status >> >> For action 1 you can look at the code in 'handle_interconnect_cb' >> function: >> >> if(queueEntry->request->get_type() == MEMORY_OP_UPDATE && >> wt_disabled_ == false) { >> if(type_ == L2_CACHE || type_ == L3_CACHE) { >> memdebug("L2/L3 cache update sending to >> lower\n"); >> queueEntry->eventFlags[ >> CACHE_WAIT_INTERCONNECT_EVENT]++; >> queueEntry->sendTo = lowerInterconnect_; >> >> memoryHierarchy_->add_event(&waitInterconnect_, >> 0, queueEntry); >> } >> >> } >> >> Here we send the request to lower cache or memory when we see a memory >> update. >> So even if there is a cache miss the line will be update in RAM. >> >> This model has issue that even if we have cache hit it will update RAM >> so when there are frequent memory-update requests then the RAM >> bandwidth will be occupied by this requests. We can improve this model >> to send update to lower cache only when there is a cache miss. >> >> I hope this answers your question. And thanks for noticing this issue, >> we can improve the cache model to send update only when required. >> >> Thanks, >> Avadh >> >> > >> > I really appreciate your help. >> > zhe >> > >> > 2010/11/9 avadh patel <[email protected]> >> >> >> >> >> >> On Tue, Nov 9, 2010 at 1:48 PM, Zhe Wang <[email protected]> wrote: >> >>> >> >>> Hi, Avadh, >> >>> >> >>> Thanks for your quick reply. It is really helpful. >> >>> >> >>> I am wondering what kind of write back policy marss use, write back >> allocate or write back non allocate? Since if using write back allocate, >> every write miss should incur a load from main memory. I have not figured >> it out from marss code. >> >>> >> >> It uses write-back allocate method to load the remaining parts of a >> cache-line from main memory when there is a cache-miss. >> >> On a write-miss, it does send the request to lower-cache or RAM to fill >> in the line. So all the request of type Memory_op_write you see in RAM is >> caused by a cache-miss and requested a line to fill in from RAM. >> >> - Avadh >> >> >> >>> >> >>> Thanks >> >>> >> >>> Best >> >>> zhe >> >>> >> >>> 2010/11/9 avadh patel <[email protected]> >> >>>> >> >>>> On Tue, Nov 9, 2010 at 12:04 PM, zhe <[email protected]> wrote: >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> I do not understand the memory_op_update and memory_op_write >> >>>>> operation in the uniprocessor marss write-back configuration. >> >>>>> >> >>>> Write-back configured caches uses 'memory_op_update' type of >> configuration >> >>>> to perform a 'write-back' when they are evicting a dirty line. >> >>>> While 'memory_op_write' is mainly used by 'CPU' to generate a write >> cache >> >>>> access. If this misses in caches then it will use same request type >> to load >> >>>> data from RAM. >> >>>> >> >>>>> >> >>>>> It seems there are both memory_op_update and memory_op_write >> >>>>> operation for the main memory access. And it seems there are >> >>>>> memory_op_write operation with no data. >> >>>>> >> >>>> >> >>>> All caches and simulated RAM model doesn't contain any data. Actual >> data >> >>>> is stored in QEMU's emulated RAM model. So none of the simulated >> cache or >> >>>> RAM access contains data. >> >>>>> >> >>>>> I am wondering what is the meaning of memory_op_update and >> >>>>> memory_op_write operation in the uniprocessor marss write-back >> >>>>> configuration? >> >>>>> >> >>>> memory_op_write - Generated by CPU for write to a cache line, if it >> misses in >> >>>> cache then it sends request to lower >> level caches. >> >>>> memory_op_update - Generated by Caches when evicting a dirty line or >> flushing. >> >>>> - Avadh >> >>>>> >> >>>>> Thank you! >> >>>>> >> >>>>> zhe >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> http://www.marss86.org >> >>>>> Marss86-Devel mailing list >> >>>>> [email protected] >> >>>>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >> >>>> >> >>> >> >> >> > >> > > > _______________________________________________ > http://www.marss86.org > Marss86-Devel mailing list > [email protected] > https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel > >
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
