Thank you Steve, I will check that.

Saludos
             Roberto


On Fri, Jun 21, 2013 at 7:00 PM, Steve Reinhardt <[email protected]> wrote:

> I'm not 100% clear on what you're doing, but note that the only time
> tags->insertBlock() is called from access() is when you have a writeback
> (as that's the only time there's a block to insert right away on an
> access).  Normally tags->insertBlock() is called from handleFill(), which
> is where you end up after you receive the response to a miss.
>
> Steve
>
>
> On Fri, Jun 21, 2013 at 9:31 AM, Roberto Rodríguez-Rodríguez <
> [email protected]> wrote:
>
>> Thanks for your answers, I will try with the ContextId,
>>
>> I am checking the insertions in cache_impl.hh access method before the
>> calling to tags->accessBlock, I do this:
>>
>>  bool isWriteback=false;
>>  if (pkt->cmd == MemCmd::Writeback)
>>   isWriteback=true;
>>
>> Later I use this flag for the tags->insertBlock method.
>>
>>
>> Best Regards
>>
>>              Roberto
>>
>>
>> On Fri, Jun 21, 2013 at 6:13 PM, Steve Reinhardt <[email protected]>wrote:
>>
>>> Good point... the blocks do get inserted in the intermediate caches on
>>> the way up.  Not enough coffee before answering.  Perhaps Roberto is
>>> checking insertions in the wrong place?
>>>
>>> Steve
>>>
>>>
>>> On Fri, Jun 21, 2013 at 8:11 AM, biswabandan panda 
>>> <[email protected]>wrote:
>>>
>>>> @Roberto - you could use the ContextId to distinguish the writebacks
>>>> from the demand misses. Writebacks have contextId -1.
>>>>
>>>> @Steve - gem5 hierarchy is non-inclusive but the explanation you gave
>>>> was for exclusive cache hierarchy. In a non-inclusive cache demand
>>>> responses go through all the levels of cache.
>>>>
>>>> You can refer Achieving Non-Inclusive Cache Performance With Inclusive
>>>> Caches -- Temporal Locality Aware (TLA) Cache Management 
>>>> Policies"<http://www.jaleels.org/ajaleel/publications/micro2010-tla.pdf>,
>>>> for clarification
>>>>
>>>>
>>>> On Fri, Jun 21, 2013 at 8:10 PM, Steve Reinhardt <[email protected]>wrote:
>>>>
>>>>> In the classic (non-Ruby) memory system, the cache hierarchy is
>>>>> non-inclusive, so demand misses go straight to the L1 cache.  Blocks only
>>>>> get inserted in levels other than the L1 due to writebacks (and possibly
>>>>> prefetches, if you have a prefetcher associated with that level of cache).
>>>>>
>>>>> Steve
>>>>>
>>>>>
>>>>> On Fri, Jun 21, 2013 at 6:03 AM, Roberto Rodríguez-Rodríguez <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hello everyone,
>>>>>>
>>>>>> I am working with cache replacement policies, in the LLC I need to
>>>>>> distinguish between an insertion because of a writeback or because
>>>>>> of a miss in all cache levels.
>>>>>>
>>>>>> I thought it could be done using the packet command type (pkt->cmd==
>>>>>> MemCmd::Writeback). I did it but all the insertions are writebacks,
>>>>>> there is not an insertion because of a miss in all levels, I tested it 
>>>>>> with
>>>>>> 1 billion instructions of the spec2006.
>>>>>>
>>>>>>
>>>>>> Best Regards
>>>>>>
>>>>>>              Roberto
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *thanks&regards
>>>> *
>>>> *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
>>>> [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
>>
>
>
> _______________________________________________
> 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

Reply via email to