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
