Changes between Version 61 and Version 62 of replication_distribution

Timestamp:

Dec 20, 2019, 12:44:19 AM (4 years ago)

Author:

alain

Comment:

--

replication_distribution

@@ -105 +105 @@
 === 3.1 KCODE ===
 
-The '''KCODE''' segment contains the kernel code defined in the ''kernel.elf'' file.  To avoid contention and improve locality, almos-mkh replicates this code in all clusters. This code has already been copied in all clusters by the bootloader. In each cluster K, and for each process P in cluster K (including the kernel process_zero), almos-mkh registers the KCODE vseg in all VSL(P,K), and map it to the local copy in all the GPT(P,K). This vseg uses only big pages, and there is no on-demand paging for this type of vseg. With this local mapping all access to the virtual instruction addresses will be simply translated by the MMU to the local physical address.
+The '''KCODE''' segment contains the kernel code defined in the ''kernel.elf'' file.  To avoid contention and improve locality, almos-mkh replicates this code in all clusters. This code has already been copied in all clusters by the bootloader. 
 
 '''WARNING''' : there is only one segment defined in the ''kernel.elf'' file, but there is as many KCODE vsegs as the number of clusters. All these vsegs have the same virtual base address and the same size, but the physical adresses (defined in the GPTs) depend on the cluster, because we want to access the local copy.
 This is not a problem because A KCODE vseg is a ''private'' vseg, that is accessed only by local threads. 
+
+In each cluster K, and for each process P in cluster K (including the kernel process_zero), almos-mkh registers the KCODE vseg in all VSL(P,K), and map it in all the GPT(P,K). 
+This vseg uses only big pages, and there is no on-demand paging for this type of vseg. 
 
 === 3.2 KDATA ===
@@ -140 +143 @@
 Almos-mkh defines two different policies to access the data stored in the N  KDATA and KHEAP segments :
  * The local accesses to the local kernel structures can use normal pointers that will be translated by the MMU to local physical adresses. 
- * The remote access to remotely allocated kernel structures '''must''' use  the ''hal_remote_load( cxy , ptr )'' and ''hal_remote_store( cxy , ptr ) functions, where ''ptr'' is a normal pointer to the KDATA or KHEAP vseg, and ''cxy'' is the remote cluster identifier. Notice that a kernel global (shared) variable is identified by and extended pointer ''XPTR( cxy , ptr )''. With these remote access primitives, any kernel instance in any cluster can access any global variable in any cluster. 
+ * The remote access to remote kernel structures '''must''' use  the ''hal_remote_load( cxy , ptr )'' and ''hal_remote_store( cxy , ptr )'' functions, where ''ptr'' is a normal pointer to the KDATA or KHEAP vseg, and ''cxy'' is the remote cluster identifier. Notice that a non local kernel variable is therefore identified by and extended pointer ''XPTR( cxy , ptr )''. With these remote access primitives, any kernel instance in any cluster can access any variable in any other cluster. 
 
 In other words, almost-mkh clearly distinguish the ''local accesses'', that can use standard pointers, from the ''remote access'' that must use extended pointers. 
-This can be seen as a bad constraint, but it clearly to improve locality and avoid  contention .
+This can be seen as a bad constraint, but it clearly help to improve locality and avoid  contention .
 
 The remote_access primitives API is defined in the  [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/hal/generic/hal_remote.h  almos_mkh/hal/generic/hal_remote.h] file.
-
-The implementation of this API for the TSAR architecture is defined in the [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/hal/tsar_mip32/core/hal_remote.c almos_mkh/hal/tsar_mips32/core/hal_remote.c] file.
 
 == __4. Remote accesses implementation__ ==