Changeset 651 for trunk/kernel/mm/vmm.h

Timestamp:

Nov 14, 2019, 11:50:09 AM (4 years ago)

Author:

alain

Message:

1) Improve the VMM MMAP allocator: implement the "buddy" algorithm
to allocate only aligned blocks.
2) fix a bug in the pthread_join() / pthread_exit() mmechanism.

File:

• trunk/kernel/mm/vmm.h (modified) (6 diffs)

trunk/kernel/mm/vmm.h

@@ -64 +64 @@
 
 /*********************************************************************************************
- * This structure defines the MMAP allocator used by the VMM to dynamically handle  
- * MMAP vsegs requested or released by an user process.
- * This allocator should be only used in the reference cluster.
- * - allocation policy : all allocated vsegs occupy an integer number of pages that is
- *   power of 2, and are aligned on a page boundary. The requested number of pages is
- *   rounded if required. The first_free_vpn variable defines completely the MMAP zone state.
- *   It is never decremented, as the released vsegs are simply registered in a zombi_list.
- *   The relevant zombi_list is checked first for each allocation request.
- * - release policy : a released MMAP vseg is registered in an array of zombi_lists.
- *   This array is indexed by ln(number of pages), and each entry contains the root of
- *   a local list of zombi vsegs that have the same size. The physical memory allocated
- *   for a zombi vseg descriptor is not released, to use the "list" field.
- *   This physical memory allocated for MMAP vseg descriptors is actually released
- *   when the VMM is destroyed.
+ * This structure defines the MMAP allocator used by the VMM to dynamically handle MMAP vsegs
+ * requested or released by an user process. It must be called in the reference cluster.
+ * - allocation policy : 
+ *   This allocator implements the buddy algorithm. All allocated vsegs occupy an integer
+ *   number of pages, that is power of 2, and are aligned (vpn_base is multiple of vpn_size).
+ *   The requested number of pages is rounded if required. The global allocator state is
+ *   completely defined by the free_pages_root[] array indexed by the vseg order.
+ *   These free lists are local, but are implemented as xlist because we use the existing
+ *   vseg.xlist to register a free vseg in its free list.
+ * - release policy : 
+ *   A released vseg is recursively merged with the "buddy" vseg when it is free, in
+ *   order to build the largest possible aligned free vsegs. The resulting vseg.vpn_size
+ *   field is updated.
+ * Implementation note:
+ * The only significant (and documented) fiels in the vsegs registered in the MMAP allocator
+ * free lists are "xlist", "vpn_base", and "vpn_size".
  ********************************************************************************************/
 
@@ -85 +87 @@
     vpn_t          vpn_base;           /*! first page of MMAP zone                          */
     vpn_t          vpn_size;           /*! number of pages in MMAP zone                     */
-    vpn_t          first_free_vpn;     /*! first free page in MMAP zone                     */
-    xlist_entry_t  zombi_list[32];     /*! array of roots of released vsegs lists           */
+    xlist_entry_t  free_list_root[CONFIG_VMM_HEAP_MAX_ORDER + 1];  /* roots of free lists   */
 }
 mmap_mgr_t;
@@ -103 +104 @@
  * 2. The VSL contains only local vsegs, but it is implemented as an xlist, and protected by
  *    a remote_rwlock, because it can be accessed by a thread running in a remote cluster.
- *    An exemple is the vmm_fork_copy() function.
+ *    An example is the vmm_fork_copy() function.
  * 3. The GPT in the reference cluster can be directly accessed by remote threads to handle
  *    false page-fault (page is mapped in the reference GPT, but the PTE copy is missing
@@ -119 +120 @@
 
     stack_mgr_t        stack_mgr;           /*! embedded STACK vsegs allocator              */
+
     mmap_mgr_t         mmap_mgr;            /*! embedded MMAP vsegs allocator               */
 
@@ -156 +158 @@
  * call to the vmm_user_init() function after an exec() syscall.
  * It removes from the VMM of the process identified by the <process> argument all
- * non kernel vsegs (i.e. all user vsegs), by calling the vmm_remove_vseg() function.
+ * all user vsegs, by calling the vmm_remove_vseg() function.
  * - the vsegs are removed from the VSL.
  * - the corresponding GPT entries are removed from the GPT.
@@ -279 +281 @@
 /*********************************************************************************************
  * This function allocates memory for a vseg descriptor, initialises it, and register it
- * in the VSL of the local process descriptor, that must be the reference process.
- * - For the FILE, ANON, & REMOTE types, it does not use the <base> and <size> arguments,
- *   but uses the specific MMAP virtual memory allocator.
+ * in the VSL of the local process descriptor.
+ * - For the FILE, ANON, & REMOTE types, it does not use the <base> argument, but uses 
+ *   the specific VMM MMAP allocator.
  * - For the STACK type, it does not use the <base> and <size> arguments,  but uses the
- *   and the <base> argument the specific STACK virtual memory allocator.
+ *   the specific VMM STACK allocator.
  * It checks collision with pre-existing vsegs.
  * To comply with the "on-demand" paging policy, this function does NOT modify the GPT,