1
1
openmpi/oshmem/mca/memheap
Ralph Castain 552c9ca5a0 George did the work and deserves all the credit for it. Ralph did the merge, and deserves whatever blame results from errors in it :-)
WHAT:    Open our low-level communication infrastructure by moving all necessary components (btl/rcache/allocator/mpool) down in OPAL

All the components required for inter-process communications are currently deeply integrated in the OMPI layer. Several groups/institutions have express interest in having a more generic communication infrastructure, without all the OMPI layer dependencies.  This communication layer should be made available at a different software level, available to all layers in the Open MPI software stack. As an example, our ORTE layer could replace the current OOB and instead use the BTL directly, gaining access to more reactive network interfaces than TCP.  Similarly, external software libraries could take advantage of our highly optimized AM (active message) communication layer for their own purpose.  UTK with support from Sandia, developped a version of Open MPI where the entire communication infrastucture has been moved down to OPAL (btl/rcache/allocator/mpool). Most of the moved components have been updated to match the new schema, with few exceptions (mainly BTLs where I have no way of compiling/testing them). Thus, the completion of this RFC is tied to being able to completing this move for all BTLs. For this we need help from the rest of the Open MPI community, especially those supporting some of the BTLs.  A non-exhaustive list of BTLs that qualify here is: mx, portals4, scif, udapl, ugni, usnic.

This commit was SVN r32317.
2014-07-26 00:47:28 +00:00
..
base George did the work and deserves all the credit for it. Ralph did the merge, and deserves whatever blame results from errors in it :-) 2014-07-26 00:47:28 +00:00
buddy George did the work and deserves all the credit for it. Ralph did the merge, and deserves whatever blame results from errors in it :-) 2014-07-26 00:47:28 +00:00
ptmalloc George did the work and deserves all the credit for it. Ralph did the merge, and deserves whatever blame results from errors in it :-) 2014-07-26 00:47:28 +00:00
configure.m4 OSHMEM: memheap framework fix warn, remove verbs deps 2014-02-27 07:22:57 +00:00
Makefile.am Use the correct abstraction layer name for the data dirs 2014-05-08 14:32:24 +00:00
memheap.h oshmem: fix warnings 2014-07-11 13:25:09 +00:00
README Per the RFC schedule, this commit adds Mellanox OpenSHMEM to the trunk. It does not yet run on OSX or with CM PML for an MTL other than MXM. Mellanox is aware of these issues and is in the process of resolving them. This should be added to \ncmr=v1.7.4:subject=Move OSHMEM to 1.7.4:reviewer=rhc 2013-09-10 15:34:09 +00:00

# Copyright (c) 2013      Mellanox Technologies, Inc.
#                         All rights reserved
# $COPYRIGHT$
MEMHEAP Infrustructure documentation
------------------------------------

MEMHEAP Infrustructure is responsible for managing the symmetric heap.
The framework currently has following components: buddy and ptmalloc. buddy which uses a buddy allocator in order to manage the Memory allocations on the symmetric heap. Ptmalloc is an adaptation of ptmalloc3. 

Additional components may be added easily to the framework by defining the component's and the module's base and extended structures, and their funtionalities.

The buddy allocator has the following data structures: 
1. Base component - of type struct mca_memheap_base_component_2_0_0_t
2. Base module - of type struct mca_memheap_base_module_t 
3. Buddy component - of type struct mca_memheap_base_component_2_0_0_t
4. Buddy module - of type struct mca_memheap_buddy_module_t extending the base module (struct mca_memheap_base_module_t)

Each data structure includes the following fields:
1. Base component - memheap_version, memheap_data and memheap_init
2. Base module - Holds pointers to the base component and to the functions: alloc, free and finalize
3. Buddy component - is a base component.
4. Buddy module - Extends the base module and holds additional data on the components's priority, buddy allocator, 
   maximal order of the symmetric heap, symmetric heap, pointer to the symmetric heap and hashtable maintaining the size of each allocated address.

In the case that the user decides to implement additional components, the Memheap infrastructure chooses a component with the maximal priority.
Handling the component opening is done under the base directory, in three stages: 
1. Open all available components. Implemented by memheap_base_open.c and called from shmem_init. 
2. Select the maximal priority component. This procedure involves the initialization of all components and then their
   finalization except to the chosen component. It is implemented by memheap_base_select.c and called from shmem_init.
3. Close the max priority active cmponent. Implemented by memheap_base_close.c and called from shmem finalize. 

 
Buddy Component/Module
----------------------

Responsible for handling the entire activities of the symmetric heap.
The supported activities are: 
                            - buddy_init (Initialization) 
                            - buddy_alloc (Allocates a variable on the symmetric heap)
                            - buddy_free (frees a variable previously allocated on the symetric heap)
                            - buddy_finalize (Finalization).
 
Data members of buddy module: - priority. The module's priority.
                              - buddy allocator: bits, num_free, lock and the maximal order (log2 of the maximal size) 
                                of a variable on the symmetric heap. Buddy Allocator gives the offset in the symmetric heap
                                where a variable should be allocated. 
                              - symmetric_heap: a range of reserved addresses (equal in all executing PE's) dedicated to "shared memory" allocation.
                              - symmetric_heap_hashtable (holding the size of an allocated variable on the symmetric heap.
                                 used to free an allocated variable on the symmetric heap)