Changes between Version 31 and Version 32 of processus_thread


Ignore:
Timestamp:
Sep 16, 2016, 9:34:24 PM (6 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • processus_thread

    v31 v32  
    44
    55The process is the internal représentation of an user application. A process can be running as a single thread (called main thread), or can be multi-threaded. ALMOS-MK supports the POSIX thread API.
    6 For a multi-threaded application, the number of threads can be very large, and the threads of a given process can be distributed on all cores available in the shared memory architecture, for maximal parallelism. Therefore A single process can spread on all clusters. To avoid contention, the process descriptor of a P process, and the associated structures, such as the Page Table, or the Open File Descriptors Table  are  (partially) replicated in all clusters containing at least one thread of P.
     6For a multi-threaded application, the number of threads can be very large, and the threads of a given process can be distributed on all cores available in the shared memory architecture, for maximal parallelism. Therefore A single process can spread on all clusters. To avoid contention, the process descriptor of a P process, and the associated structures, such as the list of registered vsegs ('''VSL'''), the generic page table ('''GPT'''), or the file descriptors table ('''FDT''')  are  (partially) replicated in all clusters containing at least one thread of P.
    77
    88== __1) Process__ ==
     
    1010The PID (Process Identifier) is coded on 32 bits. It is unique in the system, and has a fixed format:  The 16 MSB (CXY) contain the owner cluster identifier. The  16 LSB bits (LPID) contain the local process index in owner cluster. The '''owner cluster''' is therefore defined by PID MSB bits.
    1111
    12 As it exists several copies of the process descriptors, ALMOS-MK defines a reference process descriptor, located in the '''reference cluster'''. The other copies are used as local caches,
    13 and ALMOS-MK must guaranty the coherence betweenl the reference and the copies.
     12As it exists several copies of the process descriptors, ALMOS-MK defines a reference process descriptor, located in the '''reference cluster'''. The other copies are used as local caches, and ALMOS-MK must guaranty the coherence betweenl the reference and the copies.
    1413
    15 As ALMOS-MK supports process migration, the '''reference cluster''' can be different from the '''owner process'''. The '''owner cluster''' cannot change (because the PID is fixed), but the '''reference
    16 cluster''' can change in case of process migration.
     14As ALMOS-MK supports process migration, the '''reference cluster''' can be different from the '''owner cluster'''. The '''owner cluster''' cannot change (because the PID is fixed), but the '''reference cluster''' can change in case of process migration.
    1715
    1816In each cluster K, the local cluster manager (cluster_t type in ALMOS-MK) contains a process manager (pmgr_t type in ALMOS-MK) that maintains three structures for all process owned by K :
     
    2523- '''PPID''' : parent process identifier,
    2624- '''PREF''' : extended pointer on the reference process descriptor.
    27 - '''VSEG_LIST''' : root of the local list of virtual segments defining the memory image.
    28 - '''PG_TBL''' : page table defining the physical memory mapping.
    29 - '''FD_TBL''' : open file descriptors table.
     25- '''VSL''' : root of the local list of virtual segments defining the memory image.
     26- '''GPT''' : generic page table defining the physical memory mapping.
     27- '''FDT''' : open file descriptors table.
    3028- '''TH_TBL''' : local table of threads owned by this process in this cluster.
    3129- '''LOCAL_LIST''' : member of local list of all process descriptors in same cluster.
     
    7472The process creation in a remote cluster implement the POSIX fork() / exec()  mechanism.
    7573When a parent process P executes the fork() system call, a new child process C is created.
    76 The new C process inherit from the parent process P the open files (FD_TBL), and the memory image (VSEG_LIST and PG_TBL). These structures must be replicated in the new process descriptor. After a fork(), the C process can execute an exec() system call, that allocate a new memory image to the C process, but the new process can also continue to execute with the inherited memory image. For load balancing, ALMOS-MK  uses the DQDT to create the child process C on a different cluster from the parent cluster P, but the user application can also use the fork_place() system call to specify the target cluster.
     74The new C process inherit from the parent process P the open files (FDT), and the memory image (VSL and GPT). These structures must be replicated in the new process descriptor. After a fork(), the C process can execute an exec() system call, that allocate a new memory image to the C process, but the new process can also continue to execute with the inherited memory image. For load balancing, ALMOS-MK  uses the DQDT to create the child process C on a different cluster from the parent cluster P, but the user application can also use the fork_place() system call to specify the target cluster.
    7775
    7876=== 3.1) fork() ===
    7977
    80 The parent process P is running on a core in cluster K, and executes the fork() system call to create a new process C on a remote cluster Z that will  become the owner of the C process. ALMOS-MK creates the first C process descriptor in the same cluster as the parent cluster P, and postpone the costly remote copy of page table from P to C, because this copy is useless in case of exec(). When the fork() system call returns, the C process owner cluster is Z, but the reference process descriptor is in cluster K. The child process and the associated main thread will be migrated to the target cluster later, when the child process makes an "exec" or any other system call.
     78The parent process P is running on a core in cluster K, and executes the fork() system call to create a new process C on a remote cluster Z that will  become the owner of the C process. ALMOS-MK creates the first C process descriptor in the same cluster as the parent cluster P, and postpone the costly remote copy of VSL and GPT from P to C, because this copy is useless in case of exec(). When the fork() system call returns, the C process owner cluster is Z, but the reference process descriptor is in cluster K. The child process and the associated main thread will be migrated to cluster Z later, when the child process makes an "exec" or any other system call.
    8179
    8280 1. the cluster K allocates memory in K for the reference process descriptor of C, and get a pointer on this process descriptor.
    83  1. the cluster K ask to kernel Z to allocate a PID for the F process, and to register the process descriptor extended pointer in its PREF_TBL(Z). It uses the RPC_PROCESS_PID_ALLOC that takes the process descriptor pointer as argument and returns the PID.
    84  1. after RPC completion, the kernel K initializes the C process descriptor from informations found in the P parent process descriptor. This includes the inherited ...
     81 1. the cluster K ask to kernel Z to allocate a PID for the C process, and to register the process descriptor extended pointer in its PREF_TBL(Z). It uses the RPC_PROCESS_PID_ALLOC that takes the process descriptor pointer as argument and returns the PID.
     82 1. after RPC completion, the kernel K initializes the C process descriptor from informations found in the P parent process descriptor.
    8583 1. the kernel K creates locally the main thread of process C, and register this thread in the TH_TBL(K,P),
    8684 1. the kernel K register this new thread in the scheduler of the core executing the fork() system call, an return.
     
    9088=== 3.2) exec() ===
    9189
    92 After a fork() system call, the F process can execute an exec() system call. This system call forces the F process to migrate from the K cluster to the owner cluster Z, to execute a new application, while keeping the same PID. Therefore a new reference process descriptor , and the associated main thread are created in  the Z cluster, and initialized from values found in the .elf file defining the new application. The Z cluster  becomes both the owner and the reference cluster of the F process. The old reference process descriptor and the associated thread in K are deleted.
     90After a fork() system call, the C process can execute an exec() system call. This system call forces the C process to migrate from the K cluster to the owner cluster Z, to execute a new application, while keeping the same PID. Therefore a new reference process descriptor , and the associated main thread are created in  the Z cluster, and initialized from values found in the .elf file defining the new application. The Z cluster  becomes both the owner and the reference cluster of the C process. The old reference process descriptor for C, and the associated thread in K are deleted.
    9391
    94  1. The kernel K send an RPC_PROCESS_MIGRATE to cluster Z. The argument are the extended pointer on the F process descriptor in cluster K.
     92 1. The kernel K send an RPC_PROCESS_MIGRATE to cluster Z. The argument are the extended pointer on the C process descriptor in cluster K.
    9593 1. To execute this RPC, the kernel Z allocates a new reference process descriptor in cluster Z, and initializes it from informations found in process descriptor in cluster K, using a remote_memcpy().
    96  1. The kernel Z allocates and initializes from disk the  structures contained in the process VMM: PG_TBL(Z,C), VSEG_LIST(Z,C).
    97  1. The kernel Z creates the main thread associated to process P in cluster Z, initializes it, and register it in the TH_TBL(Z,P).
     94 1. The kernel Z allocates and initializes from disk the  structures contained in the process VMM: GPT(Z,C), VSL(Z,C).
     95 1. The kernel Z creates the main thread associated to process C in cluster Z, initializes it, and register it in the TH_TBL(Z,C).
    9896 1. The kernel Z registers this thread in the scheduler of the core selected by the Z kernel and acknowledges the RPC.
    99  1. When receiving the RPC acknowledge, the kernel K destroy the F process descriptor and the associated thread in cluster K, that is not anymore involved in process F execution.
     97 1. When receiving the RPC acknowledge, the kernel K destroy the C process descriptor and the associated thread in cluster K, that is not anymore involved in process C execution.
    10098
    101 At the end of the exec() system call, the cluster Z is both the owner and the reference cluster for process F, that contains one single thread in cluster Z.
     99At the end of the exec() system call, the cluster Z is both the owner and the reference cluster for process C, that contains one single thread in cluster Z.
    102100
    103101=== 3.3) No exec() ===
    104102
    105103If the new C process does not execute the exec() system call, but executes another system call, the C process migrate from K to Z,
    106 as in previous section, but the structures contained in the VMM (PG_TBL(Z,C) and VSEG_LIST(Z,C) are replicated from the values contained in process P, using a remote memcopy().
     104as in previous section, but the structures contained in the VMM (GPT(Z,C) and VSL(Z,C) are replicated from the values contained in parent process P, using a remote memcopy().
    107105
    108106== __4) Thread creation__ ==