Changes between Version 29 and Version 30 of replication_distribution


Ignore:
Timestamp:
Sep 19, 2017, 5:29:32 PM (7 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • replication_distribution

    v29 v30  
    44
    55The replication / distribution policy has two goals: enforce locality (as much as possible), and avoid contention (it is the main goal).
    6  * The read-only segments (type CODE) are replicated in all clusters where they are used.
    7  * The private  segments (type STACK) are placed in the same cluster as the thread using it.
    8  * The shared segments (types DATA or HEAP ) are distributed on all clusters as regularly as possible to avoid contention.
    9  * The pinned segments (types FILE or REMOTE) are placed in the specified cluster.
     6 * The read-only segment containing the user code is replicated in all clusters where there is a 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.
     8 * The shared segment containing the global data is distributed on all clusters as regularly as possible to avoid contention.
     9 * The segments dynamically allocated by the mmap() system call are placed in a specific cluster as described below.
    1010
    1111To actually control data placement on the physical memory banks, the kernel uses the paged virtual memory MMU to map a virtual segment to a given physical memory bank.
     
    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. It is 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 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,
     16and 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.
    1617
    17 For 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. In each active cluster K, the virtual memory manager VMM(P,K) is stored in the local process descriptor, and contains two main structures:
     18For 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:
    1819 * the VSL(P,K) is the list of all vsegs registered for process P in cluster K,
    1920 * the GPT(P,K) is the generic page table, defining the actual physical mapping of those vsegs.
     
    2223
    2324 * 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.
    24  * For a '''public''' vseg ALMOS-MK implements a global mapping : In all clusters, a given virtual address is mapped to the same physical address. For a '''private''' vseg, ALMOS-MK 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.
    2526 * 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'''.
    2627
    27 ALMOS-MK defines seven vseg types:
     28ALMOS-MK defines six vseg types:
    2829|| type        ||               ||                  ||                                                                                 ||
    2930|| STACK    ||  private  || localized    || Read Write || one physical mapping per thread        ||
    3031|| CODE     ||  private   || localized   || Read Only   || one physical mapping per cluster       ||
    3132|| DATA       ||  public   || distributed || Read Write || one single physical mapping               ||
    32 || HEAP      ||  public   || distributed || Read Write || one single physical mapping               ||
    3333|| ANON     ||  public   || localized    || Read Write || one per mmap(anon)                          ||
    3434|| FILE        ||  public   || localized    || Read Write || one per mmap(file)                              ||
    3535|| REMOTE ||  public   || localized    || Read Write || one per remote_mmap()                      ||
    3636
    37  1. '''CODE''' : This private vseg contains the user application code. ALMOS-MK creates one CODE vseg per 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 cluster X, the CODE vseg is physically mapped in cluster X.
    38  1. '''DATA''' : This vseg contains the user application global data. ALMOS-MK creates one single DATA vseg per process, that is registered in the reference VSL(P,Z) when the process P is created in reference cluster Z.  In the other clusters X, the DATA vseg is registered  in VSL(P,X) when a page fault is signaled by a thread of P running in cluster X. To avoid contention, this vseg is physically distributed on all clusters. For each page, the physical mapping is decided by the reference cluster Z, but the page can be mapped on any cluster Y.
    39  1. '''HEAP''' This vseg is actually used by the malloc() library. ALMOS-MK creates one single HEAP vseg per process, that is registered in the reference VSL(P,Z) when the process P is created in reference cluster Z.  In the other clusters X, the HEAP vseg is registered  in VSL(P,X) when a page fault is signaled by a thread of P running in cluster X. To avoid contention, this vseg is physically distributed on all clusters. For each page, the physical mapping is decided by the reference cluster Z, but the page can be mapped on any cluster Y.
     37 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.
     38 1. '''DATA''' : This vseg contains the user application global data. ALMOS-MK creates one single DATA vseg per process, that is registered in the reference VSL(P,Z) when the process P is created in reference cluster Z.  In the other clusters X, the DATA vseg is registered  in VSL(P,X) when a page fault is signaled by a thread of P running in cluster X. To avoid contention, this vseg is physically distributed on all clusters, with a page granularity. For each page, the physical mapping is defined by the LSB bits of the page VPN.
    4039 1. '''STACK''' : This private vseg contains the execution stack of a thread. For each thread T of process P running in cluster X, ALMOS_MK creates one STACK vseg. This vseg is registered in the VSL(P,X) when the thread descriptor is created in cluster X. To enforce locality, this vseg is physically mapped in cluster X.
    4140 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.
    4241 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.
    43  1. '''REMOTE''' : This type of vseg is dynamically created by ALMOS-MK to serve a remote_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 specified by the user.
     42 1. '''REMOTE''' : This type of vseg is dynamically created by ALMOS-MK to serve a remote 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 specified by the user.
     43
    4444
    4545The replication of the VSL(P,K) and GPT(P,K) kernel structures creates a coherence problem for the non private vsegs.