Changes between Version 31 and Version 32 of processus_thread
- Timestamp:
- Sep 16, 2016, 9:34:24 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
processus_thread
v31 v32 4 4 5 5 The 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 Tableare (partially) replicated in all clusters containing at least one thread of P.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 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. 7 7 8 8 == __1) Process__ == … … 10 10 The 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. 11 11 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. 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, and ALMOS-MK must guaranty the coherence betweenl the reference and the copies. 14 13 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. 14 As 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. 17 15 18 16 In 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 : … … 25 23 - '''PPID''' : parent process identifier, 26 24 - '''PREF''' : extended pointer on the reference process descriptor. 27 - '''VS EG_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. 30 28 - '''TH_TBL''' : local table of threads owned by this process in this cluster. 31 29 - '''LOCAL_LIST''' : member of local list of all process descriptors in same cluster. … … 74 72 The process creation in a remote cluster implement the POSIX fork() / exec() mechanism. 75 73 When 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.74 The 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. 77 75 78 76 === 3.1) fork() === 79 77 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 clusterlater, when the child process makes an "exec" or any other system call.78 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 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. 81 79 82 80 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 Fprocess, 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. 85 83 1. the kernel K creates locally the main thread of process C, and register this thread in the TH_TBL(K,P), 86 84 1. the kernel K register this new thread in the scheduler of the core executing the fork() system call, an return. … … 90 88 === 3.2) exec() === 91 89 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 descriptorand the associated thread in K are deleted.90 After 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. 93 91 94 1. The kernel K send an RPC_PROCESS_MIGRATE to cluster Z. The argument are the extended pointer on the Fprocess 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. 95 93 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). 98 96 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 Fexecution.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. 100 98 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.99 At 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. 102 100 103 101 === 3.3) No exec() === 104 102 105 103 If 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 inprocess P, using a remote memcopy().104 as 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(). 107 105 108 106 == __4) Thread creation__ ==