Changes between Version 30 and Version 31 of rpc_implementation

Timestamp:

Apr 7, 2018, 3:18:57 PM (6 years ago)

Author:

alain

Comment:

--

rpc_implementation

@@ -4 +4 @@
 
 To enforce locality for complex operations requiring a large number of remote memory accesses, the various kernel instances can communicate using RPCs (Remote Procedure Call), respecting  the client/server model. This section describe the RPC mechanism implemented by ALMOS-MKH.
-The corresponding code is defined in the ''rpc.c'' and ''rpc.h'' files. The software FIFO implementing the communication channel is defined in the ''remote_fifo.c'' and ''remote_fifo.h''.
+The corresponding code is defined in the ''rpc.c'' and ''rpc.h'' files. The software FIFO implementing the client/server communication channel is defined in the ''remote_fifo.c'' and ''remote_fifo.h''.
 
 == 1) Hardware platform assumptions ==
@@ -18 +18 @@
 
 Any client thread T running in any cluster K can send an PRC request to any cluster K'. In order to share the working load associated with RPC handling, each core in server cluster K'
-has a private RPC requests queue, where the client threads must register its RPC request. In principle, the client thread T running on the client core [i] select the waiting queue  queue [i] in server cluster K'. If it is not possible (when the number of cores in cluster K' is smaller than the number of cores in client cluster), the selected server core in server is core [0]. 
+has a private RPC requests queue, where the client threads must register its RPC request. In principle, the client thread T running on the client core [i] select the waiting queue  queue [i] in server cluster K'. If it is not possible (when the number of cores in cluster K' is smaller than the number of cores in client cluster), ALMOS-MKH selects core [0] in server cluster. 
 
-ALMOS-MKH replicates the KDATA segment (containing the kernel global variables) in all clusters, and uses the same LPA (Local Physical Address) for the KDATA segment base.
-Therefore, in two different clusters, a given global variable, identified by its LPA can have different values. This feature is used by by ALMOS-MKH to allow a client thread in cluster K to access a global variable in a server cluster K', building a physical address by concatenation of a given LPA with the CXY cluster identifier for the server cluster K'.
+ALMOS-MKH replicates the KDATA segment (containing the kernel global variables) in all clusters, and uses the same LPA (Local Physical Address) for the KDATA base in all clusters.
+Therefore, in two different clusters, a given global variable, identified by its LPA can have different values. This feature is used by by ALMOS-MKH to allow a client thread in cluster K to access a global variable in a server cluster K', building a physical address by concatenation of the LPA with the CXY cluster identifier for the server cluster K'.
 
-For each core [i] in a cluster K, ALMOS-MKH implement the RPC requests queue as a software RPC_FIFO[i,k]], implemented as a global variable in the KDATA segment. More precisely, each RPC_FIFO[i] has the type ''remote_fifo_t'', and is a member of the "cluster_manager" structure of cluster [k]. 
+For each core [i] in a cluster K, ALMOS-MKH implement the RPC requests queue as a software RPC_FIFO[i,k], implemented as a global variable in the KDATA segment. More precisely, each RPC_FIFO[i] has the type ''remote_fifo_t'', and is a member of the "cluster_manager" structure of cluster [k]. 
 
 This RPC_FIFO has been designed to support a large number (N) of concurrent writers, an a small number (M) of readers:
- * N is the number of client threads (practically unbounded). A client thread can execute in any cluster, and can send a RPC request to any target cluster K. To synchronize these multiple client threads, the RPC FIFO implements a "ticket based" policy, defining a ''first arrived / first served'' priority to register a new request into a given RPC_FIFO[i,k].
+ * N is the number of client threads (practically unbounded). A client thread can execute in any cluster, and can send a RPC request to any target cluster K. To synchronize these multiple client threads, each RPC_FIFO[i,k] implements a "ticket based" policy, defining a ''first arrived / first served'' priority to register a new request into a given RPC_FIFO[i,k].
  * M is the number of server threads in charge of handling RPC requests stored in a given RPC_FIFO[i,k]. M is bounded by the CONFIG_RPC_THREAD_MAX parameter. For each PRC_FIFO[i,k], it can exist several server threads, because we must avoid the ''head-of-line" blocking phenomenon, when a given server thread handling a given RPC is blocked on a given resource. To synchronize these multiple  server threads, the RPC FIFO implements a "light lock", that is a non blocking lock: only one RPC thread at a given time can take the lock and become the FIFO owner. When the light lock is taken by RPC thread T, another RPC thread T' failing to take the lock simply returns to IDLE state.