Re: [Gems-users] SM/OM state in MOESI protocol


Date: Mon, 24 Nov 2008 01:13:34 -0600
From: "Xuehai Qian" <xuehaiq@xxxxxxxxx>
Subject: Re: [Gems-users] SM/OM state in MOESI protocol
Can some one confirm the point:

On Sun, Nov 23, 2008 at 3:43 PM, Mike Marty <mike.marty@xxxxxxxxx> wrote:


On Sun, Nov 23, 2008 at 12:30 AM, Xuehai Qian <xuehaiq@xxxxxxxxx> wrote:
Hi Everyone,
   I would like to know why in SM/OM state, if the processor issues a load, it can be considered as hit, and load can use the old copy? Because there should be an outstanding store to the same location before the load, and the load should get the new data, instead of the old copy. In MESI protocol, I noticed that SM cannot service load, which is reasonable. Can anyone help me? Thanks!
 

I don't think the transition will ever happen...making it hit might be a mistake.

In-order processor models (i.e., just Simics) will never issue multiple memory references for the same block. 

When using the Opal out-of-order processor model, I think the Ruby sequencer might still prevent two outstanding accesses for the same block.  
 
Suppose P1 issued a load to a block, and the load has already had the data (from either other cache or memory), and the load instruction hasn't been committed inside P1, in this period, other processor issues a store to the same block, there would be a invalidation arrived in P1's cache, then how does P1 handle this case? Or if the sequencer doesn't allow this situation?
 
I think it is related to memory model, and I also want to know which memory model does GEMS implement?
 
Xuehai
But I'm not sure.

--Mike


_______________________________________________
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.



[← Prev in Thread] Current Thread [Next in Thread→]