@steve
Don't you think we may have stale copy of E state in L2
cache because it may be there in L1 with some writes on it?
As per your reply if the block is in M state in L1, it won't be there in L2
in the same M state, but it's possible that if a block is in M state in L2,
it may present in L1 in some other state (not as M) like O or E . In this
case again we ll have stale value in L2 but as per gem5 we are invalidating
those blocks in the case of upgrade-request and ReadEX request inside
satisfyCpuSideRequest function, there by there is no chance of getting a
block in L2 as M with stale value, but it's possible to have stale values
for the states like E, O in L2 state with the current classic coherency
protocol.
so my point is E and O state can be stale in L2, because of the write
activities in L1.
Plz do correct me if i am wrong.
On Tue, Oct 18, 2011 at 8:37 AM, biswabandan panda <[email protected]>wrote:
> Could u send ur modified file? i ll check it in PARSEC benchmarks
>
>
> On Tue, Oct 18, 2011 at 7:55 AM, biswabandan panda <[email protected]>wrote:
>
>> What can be said about the blocks which are in E state in L2? it means
>> it's up to date with DRAM right?
>> If L2 has M , can it be sure that those blocks will not be there in L1?
>>
>>
>> Plz do reply
>>
>>
>>
>>
>> On Tue, Oct 18, 2011 at 1:45 AM, Mitch Hayenga <
>> [email protected]> wrote:
>>
>>> I actually did a slight modification of the m5 classic protocol to "fix"
>>> this.
>>>
>>> Basically, I allowed the data to remain dirty in the L2 & forwarded a
>>> version that looked clean-exclusive to the L1. The way m5 is structured,
>>> the L2 would already snoop upwards to the L1 if it got a request from below,
>>> so I modified the handleSnoop() routine to check to see if an upper level
>>> cache had asserted memInhibit() (as would be done if the L1 had written the
>>> line). If this was the case, the L2 wouldn't respond to a snoop from below
>>> in cache hierarchy. If the L1 ever evicts the data (without writing), the
>>> L2 will properly respond to later snoops/requests.
>>>
>>> So far it seems to be "ok", my definition of ok being "runs splash". And
>>> has greatly reduced the recorded number of writebacks from the L1 cache. I
>>> haven't fully verified it though.
>>>
>>>
>>> On Mon, Oct 17, 2011 at 2:56 PM, Steve Reinhardt <[email protected]>wrote:
>>>
>>>> Since the cache hierarchy doesn't enforce inclusion, neither one of
>>>> these is true.
>>>>
>>>> In general at most one cache in the system (across all levels) will be
>>>> the owner at any particular point in time. So if an L1 has a block in
>>>> M or O state, no other L1 or L2 will have it in that state.
>>>>
>>>> Steve
>>>>
>>>> On Sun, Oct 16, 2011 at 9:12 AM, biswabandan panda <[email protected]>
>>>> wrote:
>>>> > HI all,
>>>> > Whether the MOESI states in L2 (assuming last level &
>>>> shared by
>>>> > all the cores) follow cache centric or memory centric approach in the
>>>> > classic snoop based coherence protocol?
>>>> >
>>>> > Cache centric - if one of the blocks is in M state in any of the L1s
>>>> and
>>>> > that block is there in L2 then it ll be also in M state, similarly S
>>>> and O
>>>> >
>>>> > memory centric - if the blocks are in I state in L1, then the L2 ll
>>>> have
>>>> > that block (if present in L2) in O state (because L2 ll behave like an
>>>> owner
>>>> > for entire hierarchy)
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> >
>>>> > thanks®ards
>>>> > BISWABANDAN
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > 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
>>>
>>
>>
>>
>> --
>>
>> *thanks®ards
>> *
>> *BISWABANDAN*
>>
>>
>>
>>
>>
>>
>
>
> --
>
> *thanks®ards
> *
> *BISWABANDAN*
>
>
>
>
>
>
--
*thanks®ards
*
*BISWABANDAN*
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
