Re: [Gems-users] Another question on MOESI protocol

["Xuehai Qian" <xuehaiq@xxxxxxxxx>]

Yes, I think in GEMS implementation, you chose the invalidation instead of just downgrading to S.

You mean I can also choose to downgrade to S in this case?

But if I do so, there will be no transition to M, then why we should call the protocol as "MOESI"?

I guess there should be some special reason that you need the M state, can anyone tell me the reason?

 

Or I am not correct, and the M state can be eliminated? In face, MM state is more like the M in traditional sense.

 

Xuehai

On Sun, Nov 23, 2008 at 1:05 AM, Cong Wang <jameswang99@xxxxxxxxx> wrote:

Hi Xuehai:
   It seems to me that you do not want to retain the data after you
write it and some other processor requests it because it could be a
shared resource, such as a lock. And you really want to optimize for
the requester to have full writable right so that it could immediately
update the lock. But you are correct in the sense that, it doesn't
have to do this. It could just downgrade to S state instead of
invalidating. But it is just one particular implementation and you are
welcome to modify it to suit your purpose.
Regards
James Wang

On Sun, Nov 23, 2008 at 12:33 AM, Xuehai Qian <xuehaiq@xxxxxxxxx> wrote:
> Hi Everyone,
>    I have another question about the one of the cache protocols in
> GEMS(MOESI_directory).
>    Suppose the block in a cache (P1) is in MM state, and another cache(P2)
> issues a load, the result according to the protocol is P1 sends the data to
> P2, and the data is exclusive dirty, after that, P1 invalidate itself, and
> P2 has the data, and the data is in state M. Here, it is the only senario
> that the state can change to M, but why we cannot let P1 still keeps the
> data, and the after this transaction, the states in both of the caches are
> shared (P1 is O_D, P2 is S)?? Following the original protocol, if P1 later
> load the block, it will encounter a miss, and will have longer latency. The
> protocol invalidate a locally stored copy in any situation (GETX or GETS),
> the motivation or benefit of doing that is not clear to me. But if a
> modified block has migrated to another cache (for example in M or O_D)
> state, the owner cache will keep the block as long as no remote caches'
> store. Why the MM cannot be handle in this way as well? But in that case,
> there is no transition being able to move state machine to "M".
>
>    I guess there is a coner case preventing what I said above, it is good if
> you can tell me the corner case, and I will understand it.
>   Thanks!
>
> Xuehai

> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding
> "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
>
>
>



--
Regards
James Wang
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.