Changes between Version 59 and Version 60 of replication_distribution


Ignore:
Timestamp:
Dec 20, 2019, 12:24:41 AM (4 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • replication_distribution

    v59 v60  
    100100Almost-mkh defines 3 types of these kernel segments described below. To avoid contention and improve locality,these four segments are replicated or distributed in each cluster.
    101101
    102 === 3.1. KCODE ===
     102=== 3.1 KCODE ===
    103103
    104104The '''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.
    … …  
    107107This is not a problem because A KCODE vseg is a ''private'' vseg, that is accessed only by local threads.
    108108
    109 === 3.2. KDATA ===
     109=== 3.2 KDATA ===
    110110
    111111The '''KDATA''' segment contains the kernel global data,  statically allocated at compilation time, and defined in the ''kernel.elf'' file. To avoid contention and improve locality, almos-mkh defines a KDATA vseg in each cluster. The corresponding data have already been copied by the boot-loader in all clusters. 
    … …  
    118118To allows any thread running in any cluster to access the N KDATA vsegs, almos-mkh can register these N vsegs in all VSL(P,K), and map them in all GPT(P,K).
    119119
    120 === 3.3. KHEAP  ===
     120=== 3.3 KHEAP  ===
    121121
    122122The '''KHEAP''' segment contains, in each cluster K, the  kernel structures dynamically allocated by the kernel in cluster K to satisfy the users requests (such as the ''process'' descriptors, the ''thread'' descriptors, the ''vseg'' descriptors, the ''file'' descriptors, etc.). To avoid contention and improve locality, almos-mkh defines one KHEAP segment in each cluster implementing a ''physically distributed  kernel heap''. In each cluster, this KHEAP segment contains actually all physical memory that is not already allocated to store the KCODE and KDATA segments.
    … …  
    128128=== 3.4 KSTACK ===
    129129
    130 Any thread entering the kernel to execute a system call needs a kernel stack, that must be in the protected memory.
    131 This requires as many kernel stacks as the total number of threads (user threads + dedicated kernel threads) in the system.
    132 For each thread, almos-mkh implements the kernel stack in the thread descriptor, that is dynamically allocated in the KHEAP segment, when the thread is created.
    133 Therefore, there is no specific KSTACK segment for the kernel stacks.
     130Any thread entering the kernel to execute a system call needs a kernel stack, that must be in the kernel land.
     131This requires to implement in kernel land as many kernel stacks as the total number of threads (user threads + dedicated kernel threads) in the system.
     132For each thread, almos-mkh implements the kernel stack in the 16 Kbytes thread descriptor, that is dynamically allocated in the KHEAP segment, when the thread is created.
     133Therefore, there is no specific KSTACK segment type for the kernel stacks.
    134134
    135135=== 3.5 Local & Remote accesses ===
    136136
    137 Almos-mkh defines two different policies to access the shared data stored in the N  KDATA and KHEAP segments :
     137Almos-mkh defines two different policies to access the data stored in the N  KDATA and KHEAP segments :
    138138 * The local accesses to the local kernel structures can use normal pointers that will be translated by the MMU to local physical adresses.
    139  * 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 on a variable stored in the KDATA or KHEAP vseg, and ''cxy'' is the remote cluster identifier. Notice that a given kernel global variable is now identified by and extended pointer ''XPTR( cxy , ptr )''. With these remote access primitives, any kernel instance in cluster K can access any global variable in any cluster.
     139 * 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.
    140140
    141141In other words, almost-mkh clearly distinguish the ''local accesses'', that can use standard pointers, from the ''remote access'' that must use extended pointers.