Changes between Version 61 and Version 62 of replication_distribution


Ignore:
Timestamp:
Dec 20, 2019, 12:44:19 AM (2 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • replication_distribution

    v61 v62  
    105105=== 3.1 KCODE ===
    106106
    107 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.
     107The '''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.
    108108
    109109'''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.
    110110This is not a problem because A KCODE vseg is a ''private'' vseg, that is accessed only by local threads.
     111
     112In 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).
     113This vseg uses only big pages, and there is no on-demand paging for this type of vseg.
    111114
    112115=== 3.2 KDATA ===
     
    140143Almos-mkh defines two different policies to access the data stored in the N  KDATA and KHEAP segments :
    141144 * The local accesses to the local kernel structures can use normal pointers that will be translated by the MMU to local physical adresses.
    142  * 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.
     145 * 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.
    143146
    144147In other words, almost-mkh clearly distinguish the ''local accesses'', that can use standard pointers, from the ''remote access'' that must use extended pointers.
    145 This can be seen as a bad constraint, but it clearly to improve locality and avoid  contention .
     148This can be seen as a bad constraint, but it clearly help to improve locality and avoid  contention .
    146149
    147150The 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.
    148 
    149 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.
    150151
    151152== __4. Remote accesses implementation__ ==