Re: [Gems-users] question on ack counting

["Mike Marty" <mikem@xxxxxxxxxxx>]

For concurrent requests, we currently have no facility to construct exact sequences of messaging.

 

 

-----Original Message-----
From: gems-users-bounces@xxxxxxxxxxx [mailto:gems-users-bounces@xxxxxxxxxxx] On Behalf Of Liqun Cheng
Sent: Friday, February 09, 2007 8:01 PM
To: Gems Users
Subject: Re: [Gems-users] question on ack counting

 

Mike,

Thanks for the fast reply, now I think I have a much clearer picture. One last question, well, I know I've said this many times. :)
In some race conditions. For example,
// Transitions from SM
  transition(SM, Inv, IM) {
    f_sendAck;
    l_popForwardQueue;
  }
Two sharers want to upgrade at the same time, and one needs to yield to avoid deadlock. I want to understand the order of message interleaving by constructing some trace. Say in the little.trace, I have
1)   7 0x400 0 LD
2)   1 0x400 0 LD
3)   7 0x400 0 ST
4)   1 0x400 0 ST
Is there anything I can do to make sure the write from 1 gets issued after GETX from 7 reaches the home directory, but before its invalidation message arrives at node 1?

thanks
Legion

On 2/9/07, Mike Marty <mikem@xxxxxxxxxxx> wrote:

> If I add a RAC to MOESI_SMP_directory, and make the rac share the same
> controller with L1/L2, do I need to make sure the RAC is also exclsive to
> the L1/L2?

I haven't thought this completely through, but I would think you could
make it non-exclusive if you wanted.  It might get tricky...see below.

> Here is my concern. If I have a share copy in L2, and a share copy in RAC.
> When other processor asks for the exclusive copy, the follwing transition
> (S->I) will be triggered twice,. Since both RAC and L2 will send an
> invalidation acknoledge, this will definitely confuse the processor which
> does the ack counting. How to make sure only one ack be sent each
> processor?
> transition(S, Inv, I) {
>     f_sendAck;
>     l_popForwardQueue;
>  }
>

Why would the transition trigger twice?  If the global directory treats
each L1/L2/RAC node as a possible sharer, it should only recieve a single
INV message.  Then you have to ensure that every cache indeed gets
invalidated.

Pay close attention to getState and setState and how they might handle a
RAC. In the transition above, you would want to make sure that the State
in both the L1/L2 and RAC both get set to Invalid in the setState()
function.

getState() could check the status of both the L1/L2 caches and the RAC.
If it is present in both, it could return a different state to indicate
this if you wanted.

The choice of integrating a RAC into an L1/L2 controller vs. a seperate
controller is probably not clear.



> BTW, is there any protocol using distributed shared memory, ccNUMA like?
>

Any directory protocol using a Torus-like interconnect is ccNUMA.  However
your Solaris checkpoint likely treats all of memory as UMA.

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