Changes between Version 38 and Version 39 of replication_distribution


Ignore:
Timestamp:
Jun 26, 2018, 3:34:27 PM (6 years ago)
Author:
nicolas.van.phan@…
Comment:

Fix typos

Legend:

Unmodified
Added
Removed
Modified

  • replication_distribution

    v38 v39  
    44
    55The replication / distribution policy of user processes has two goals: enforce locality (as much as possible), and avoid contention (it is the main goal).
    6  * The read-only segment containing the user code is replicated in all clusters where there is one thread using it.
    7  * The private  segment containing the stack for a given thread is placed in the same cluster as the thread using it.
     6 * The read-only segment containing the user code is replicated in all clusters where there is at least one thread using it.
     7 * The private segment containing the stack for a given thread is placed in the same cluster as the thread using it.
    88 * The shared segment containing the global data is distributed on all clusters as regularly as possible to avoid contention.
    99 * The segments dynamically allocated by the mmap() system call are placed  as described below.
    … …  
    1313This replication / distribution policy is implemented by the Virtual Memory Manager (in the vmm.h / vmm.c files).
    1414
    15 A '''vseg''' is a contiguous memory zone in the process virtual space, such as all adresses in this '''vseg''' can be accessed by the process without segmentation violation: if the corresponding is not mapped, the page fault will be handled by the kernel,
    16 and a physical page will be dynamically allocated and initialized if required. A '''vseg''' contains always an integer number of pages. Depending on its type, a '''vseg''' has some specific attributes regarding access rights, replication policy, and distribution policy. The vseg descriptor is defined by the structure vseg_t in the ''vseg.h'' file.
     15A '''vseg''' is a contiguous memory zone in the process virtual space, where all adresses in this '''vseg''' can be accessed by the process without segmentation violation: if the corresponding is not mapped, the page fault will be handled by the kernel,
     16and a physical page will be dynamically allocated and initialized if required. A '''vseg''' always contains an integer number of pages. Depending on its type, a '''vseg''' has some specific attributes regarding access rights, replication policy, and distribution policy. The vseg descriptor is defined by the structure vseg_t in the ''vseg.h'' file.
    1717
    1818For each process P, the process descriptor is replicated in all clusters containing at least one thread of P, and these clusters are called active clusters. More precisely, the virtual memory manager VMM(P,K) of process P in active cluster K, contains two main structures:
    19  * the VSL(P,K) is the list of all vsegs registered for process P in cluster K,
    20  * the GPT(P,K) is the generic page table, defining the actual physical mapping of those vsegs.
     19 * The VSL(P,K) is the list of all vsegs registered for process P in cluster K,
     20 * The GPT(P,K) is the generic page table, defining the actual physical mapping of those vsegs.
    2121
    2222== __1)  User segments types and attributes__  ==
    2323
    2424 * A vseg is '''public''' when it can be accessed by any thread T of the process, whatever the cluster running the thread T.  It is '''private''' when it can only be accessed by the threads running in the cluster containing the physical memory bank where this vseg is mapped. A '''private''' vseg is entirely mapped in one single cluster K.
    25  * For a '''public''' vseg ALMOS-MKH implements a global mapping : In all clusters, a given virtual address is mapped to the same physical address. For a '''private''' vseg, ALMOS-MKH implements a local mapping : the same virtual address can be mapped to different physical addresses, in different clusters.
     25 * For a '''public''' vseg, ALMOS-MKH implements a global mapping : In all clusters, a given virtual address is mapped to the same physical address. For a '''private''' vseg, ALMOS-MKH implements a local mapping : the same virtual address can be mapped to different physical addresses, in different clusters.
    2626 * A '''public''' vseg can be '''localized''' (all vseg pages are mapped in the same cluster), or '''distributed''' (different pages are mapped on different clusters, using the virtual page number (VPN) least significant bits as distribution key). A '''private''' vseg is always '''localized'''.
    2727
    2828ALMOS-MK defines six vseg types:
    29 || type        ||               ||                  ||    access     ||      replication                                     ||    Placement                              ||  allocation policy in user space                  ||
    30 || STACK    ||  private  || localized    || Read Write || one physical mapping per thread        || same cluster as thread using it  || dynamic (one stack allocator per cluster)   ||
    31 || CODE     ||  private   || localized   || Read Only   || one physical mapping per cluster       || same cluster as thread using it  || static  (defined in .elf file)                           ||
    32 || DATA       ||  public   || distributed || Read Write || same mapping for all threads              || distributed on all clusters          || static  (defined in .elf file                            ||
    33 || ANON     ||  public   || localized    || Read Write || same mapping for all threads              || same cluster as calling thread   || dynamic (one heap allocator per process   ||
    34 || FILE        ||  public   || localized    || Read Write || same mapping for all threads              || same cluster as the file cache   || dynamic (one heap allocator per process)  ||
    35 || REMOTE ||  public   || localized    || Read Write || same mapping for all threads              || cluster defined by user             || dynamic (one heap allocator per process)  ||
     29|| Type     ||           ||                  ||    Access     ||      Replication                                     ||    Placement                              ||  Allocation policy in user space                  ||
     30|| STACK    ||  private  || localized   || Read Write || one physical mapping per thread        || same cluster as thread using it  || dynamic (one stack allocator per cluster)   ||
     31|| CODE     ||  private  || localized   || Read Only   || one physical mapping per cluster       || same cluster as thread using it  || static  (defined in .elf file)                           ||
     32|| DATA     ||  public   || distributed || Read Write || same mapping for all threads              || distributed on all clusters          || static  (defined in .elf file                            ||
     33|| ANON     ||  public   || localized   || Read Write || same mapping for all threads              || same cluster as calling thread   || dynamic (one heap allocator per process   ||
     34|| FILE     ||  public   || localized   || Read Write || same mapping for all threads              || same cluster as the file cache   || dynamic (one heap allocator per process)  ||
     35|| REMOTEnn ||  public   || localized   || Read Write || same mapping for all threads              || cluster defined by user             || dynamic (one heap allocator per process)  ||
    3636
    3737 1. '''CODE''' : This private vseg contains the user application code. ALMOS-MK creates one CODE vseg per active cluster. For a process P, the CODE vseg is registered in the VSL(P,Z) when the process is created in reference cluster Z. In the other clusters X, the CODE vseg is registered in VSL(P,X) when a page fault is signaled by a thread of P running in cluster X. In each active cluster X, the CODE vseg is localized, and physically mapped in cluster X.
    … …  
    4040 1. '''ANON''' : This type of vseg is dynamically created by ALMOS-MK to serve an anonymous mmap() system call executed by a client thread running in a cluster X. The first vseg registration and the physical mapping are done by the reference cluster Z, but the vseg is mapped in the client cluster X.
    4141 1. '''FILE''' : This type of vseg is dynamically created by ALMOS-MK to serve a file based mmap() system call executed by a client thread running in a cluster X. The first vseg registration and the physical mapping are done by the reference cluster Z, but the vseg is mapped in cluster Y containing the file cache.
    42  1. '''REMOTE''' : This type of vseg is dynamically created by ALMOS-MK to serve a remote mmap() system call where a client thread running in a cluster X request to create a new vseg mapped in another cluster Y. The first vseg registration and the physical mapping are done by the reference cluster Z, but the vseg is mapped in cluster Y specified by the user.
     42 1. '''REMOTE''' : This type of vseg is dynamically created by ALMOS-MK to serve a remote mmap() system call where a client thread running in a cluster X requests to create a new vseg mapped in another cluster Y. The first vseg registration and the physical mapping are done by the reference cluster Z, but the vseg is mapped in cluster Y specified by the user.
    4343
    4444
    … …  
    5353== __2) User process virtual space organisation__ ==
    5454
    55 The virtual address space of an user process P is split in 4 fixed size zones, defined by configuration parameters.  Each zone contains one or several vsegs, as described below.
     55The virtual address space of a user process P is split in 4 fixed size zones, defined by configuration parameters.  Each zone contains one or several vsegs, as described below.
    5656
    5757=== The ''utils'' zone ===
    5858It is located in the lower part of the virtual space, and starts a address 0. It contains the three vsegs ''kentry'', ''args'', ''envs'', whose sizes are defined by specific configuration parameters. 
    59  * The ''kentry'' vseg (CODE type) contains the HAL specific code that must be executed to enter/exit the kernel from user space (in case of interrupts, exceptions, or syscalls). It contains also the HAL specific code for context switch. For some architectures (namely the TSAR 32 bits architectures), this vseg must be identity mapped.
     59 * The ''kentry'' vseg (CODE type) contains the HAL specific code that must be executed to enter/exit the kernel from user space (in case of interrupts, exceptions, or syscalls). It also contains the HAL specific code for context switches. For some architectures (namely the TSAR 32 bits architectures), this vseg must be identity mapped.
    6060 * The ''args'' vseg (DATA type) contains the process main() arguments.
    6161 * The ''envs'' vseg (DATA type) contains the process environment variables.
    … …  
    6565
    6666=== The ''heap'' zone ===
    67 It is located on top of the '''elf''' zone, and starts at address defined by the CONFIG_VSPACE_HEAP_BASE  parameter. It contains all vsegs dynamically allocated / released  by the mmap() / munmap() system calls (i.e. FILE / ANON / REMOTE types). The VMM implements a specific MMAP allocator for this zone, implementing the ''buddy'' algorithm. The mmap( FILE ) syscall maps directly a file in user space. The user level ''malloc'' library uses the mmap( ANON ) syscall to allocate virtual memory from the heap and map it in the same cluster as the calling thread. Besides the standard malloc() function, this library implements a non-standard remote_malloc() function, that uses the mmap( REMOTE ) syscall to dynamically allocate virtual memory from the heap, and map it a remote physical cluster. 
     67It is located on top of the '''elf''' zone, and starts at the address defined by the CONFIG_VSPACE_HEAP_BASE  parameter. It contains all vsegs dynamically allocated / released  by the mmap() / munmap() system calls (i.e. FILE / ANON / REMOTE types). The VMM implements a specific MMAP allocator for this zone, implementing the ''buddy'' algorithm. The mmap( FILE ) syscall maps directly a file in user space. The user level ''malloc'' library uses the mmap( ANON ) syscall to allocate virtual memory from the heap and map it in the same cluster as the calling thread. Besides the standard malloc() function, this library implements a non-standard remote_malloc() function, that uses the mmap( REMOTE ) syscall to dynamically allocate virtual memory from the heap, and map it to a remote physical cluster. 
    6868
    6969=== The ''stack'' zone ===
    70 It is located on top of the '''mmap''' zone and starts at address defined by the CONFIG_VSPACE_STACK_BASE parameter. It contains an array of fixed size slots, and each slot contain one ''stack'' vseg. The size of a slot is defined by the CONFIG_VSPACE_STACK_SIZE. In each slot the first page is not mapped to detect stack overflow. As threads are dynamically created and destroyed, the VMM implement a specific STACK allocator for this zone, using a bitmap vector. As the ''stack'' vseg are private (the same virtual address can have different mappings, depending on the cluster) the number of slots in the '''stack''' zone defines actually the max number of threads for given process in a given cluster.
     70It is located on top of the '''mmap''' zone and starts at the address defined by the CONFIG_VSPACE_STACK_BASE parameter. It contains an array of fixed size slots, and each slot contains one ''stack'' vseg. The size of a slot is defined by the CONFIG_VSPACE_STACK_SIZE. In each slot, the first page is not mapped, in order to detect stack overflows. As threads are dynamically created and destroyed, the VMM implements a specific STACK allocator for this zone, using a bitmap vector. As the ''stack'' vsegs are private (the same virtual address can have different mappings, depending on the cluster) the number of slots in the '''stack''' zone actually defines the max number of threads for given process in a given cluster.