2004-06-15 23:46:26 +04:00
|
|
|
/*
|
2005-11-05 22:57:48 +03:00
|
|
|
* Copyright (c) 2004-2005 The Trustees of Indiana University and Indiana
|
|
|
|
* University Research and Technology
|
|
|
|
* Corporation. All rights reserved.
|
2006-04-20 23:53:45 +04:00
|
|
|
* Copyright (c) 2004-2006 The University of Tennessee and The University
|
2005-11-05 22:57:48 +03:00
|
|
|
* of Tennessee Research Foundation. All rights
|
|
|
|
* reserved.
|
2004-11-28 23:09:25 +03:00
|
|
|
* Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
|
|
|
|
* University of Stuttgart. All rights reserved.
|
2005-03-24 15:43:37 +03:00
|
|
|
* Copyright (c) 2004-2005 The Regents of the University of California.
|
|
|
|
* All rights reserved.
|
2004-11-22 04:38:40 +03:00
|
|
|
* $COPYRIGHT$
|
|
|
|
*
|
|
|
|
* Additional copyrights may follow
|
|
|
|
*
|
2004-06-15 23:46:26 +04:00
|
|
|
* $HEADER$
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef OMPI_FREE_LIST_H
|
|
|
|
#define OMPI_FREE_LIST_H
|
|
|
|
|
|
|
|
#include "ompi_config.h"
|
2006-04-13 03:27:38 +04:00
|
|
|
#include "opal/class/opal_atomic_lifo.h"
|
2008-01-15 08:44:28 +03:00
|
|
|
#include "opal/prefetch.h"
|
2005-08-15 15:02:01 +04:00
|
|
|
#include "opal/threads/threads.h"
|
2005-07-04 02:45:48 +04:00
|
|
|
#include "opal/threads/condition.h"
|
2006-02-12 04:33:29 +03:00
|
|
|
#include "ompi/constants.h"
|
2006-04-20 23:53:45 +04:00
|
|
|
#include "opal/sys/cache.h"
|
2004-06-15 23:46:26 +04:00
|
|
|
|
2004-10-21 02:31:03 +04:00
|
|
|
#if defined(c_plusplus) || defined(__cplusplus)
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
2004-06-15 23:46:26 +04:00
|
|
|
|
2006-08-24 20:38:08 +04:00
|
|
|
struct mca_mem_pool_t;
|
This commit brings in two major things:
1. Galen's fine-grain control of queue pair resources in the openib
BTL.
1. Pasha's new implementation of asychronous HCA event handling.
Pasha's new implementation doesn't take much explanation, but the new
"multifrag" stuff does.
Note that "svn merge" was not used to bring this new code from the
/tmp/ib_multifrag branch -- something Bad happened in the periodic
trunk pulls on that branch making an actual merge back to the trunk
effectively impossible (i.e., lots and lots of arbitrary conflicts and
artifical changes). :-(
== Fine-grain control of queue pair resources ==
Galen's fine-grain control of queue pair resources to the OpenIB BTL
(thanks to Gleb for fixing broken code and providing additional
functionality, Pasha for finding broken code, and Jeff for doing all
the svn work and regression testing).
Prior to this commit, the OpenIB BTL created two queue pairs: one for
eager size fragments and one for max send size fragments. When the
use of the shared receive queue (SRQ) was specified (via "-mca
btl_openib_use_srq 1"), these QPs would use a shared receive queue for
receive buffers instead of the default per-peer (PP) receive queues
and buffers. One consequence of this design is that receive buffer
utilization (the size of the data received as a percentage of the
receive buffer used for the data) was quite poor for a number of
applications.
The new design allows multiple QPs to be specified at runtime. Each
QP can be setup to use PP or SRQ receive buffers as well as giving
fine-grained control over receive buffer size, number of receive
buffers to post, when to replenish the receive queue (low water mark)
and for SRQ QPs, the number of outstanding sends can also be
specified. The following is an example of the syntax to describe QPs
to the OpenIB BTL using the new MCA parameter btl_openib_receive_queues:
{{{
-mca btl_openib_receive_queues \
"P,128,16,4;S,1024,256,128,32;S,4096,256,128,32;S,65536,256,128,32"
}}}
Each QP description is delimited by ";" (semicolon) with individual
fields of the QP description delimited by "," (comma). The above
example therefore describes 4 QPs.
The first QP is:
P,128,16,4
Meaning: per-peer receive buffer QPs are indicated by a starting field
of "P"; the first QP (shown above) is therefore a per-peer based QP.
The second field indicates the size of the receive buffer in bytes
(128 bytes). The third field indicates the number of receive buffers
to allocate to the QP (16). The fourth field indicates the low
watermark for receive buffers at which time the BTL will repost
receive buffers to the QP (4).
The second QP is:
S,1024,256,128,32
Shared receive queue based QPs are indicated by a starting field of
"S"; the second QP (shown above) is therefore a shared receive queue
based QP. The second, third and fourth fields are the same as in the
per-peer based QP. The fifth field is the number of outstanding sends
that are allowed at a given time on the QP (32). This provides a
"good enough" mechanism of flow control for some regular communication
patterns.
QPs MUST be specified in ascending receive buffer size order. This
requirement may be removed prior to 1.3 release.
This commit was SVN r15474.
2007-07-18 05:15:59 +04:00
|
|
|
struct ompi_free_list_item_t;
|
|
|
|
|
|
|
|
typedef void (*ompi_free_list_item_init_fn_t) (
|
2007-11-01 20:25:12 +03:00
|
|
|
struct ompi_free_list_item_t*, void* ctx);
|
2004-06-15 23:46:26 +04:00
|
|
|
|
|
|
|
struct ompi_free_list_t
|
|
|
|
{
|
2006-04-13 03:27:38 +04:00
|
|
|
opal_atomic_lifo_t super;
|
2004-10-20 03:58:12 +04:00
|
|
|
size_t fl_max_to_alloc;
|
|
|
|
size_t fl_num_allocated;
|
|
|
|
size_t fl_num_per_alloc;
|
|
|
|
size_t fl_num_waiting;
|
2007-11-01 19:47:44 +03:00
|
|
|
size_t fl_frag_size; /* size of the fragment descriptor */
|
|
|
|
size_t fl_frag_alignment; /* fragment descriptor alignment */
|
|
|
|
size_t fl_payload_buffer_size; /* size of payload buffer */
|
|
|
|
size_t fl_payload_buffer_alignment; /* payload buffer alignment */
|
2007-11-01 20:25:12 +03:00
|
|
|
opal_class_t* fl_frag_class;
|
2006-06-14 21:43:50 +04:00
|
|
|
struct mca_mpool_base_module_t* fl_mpool;
|
2005-07-04 02:45:48 +04:00
|
|
|
opal_mutex_t fl_lock;
|
|
|
|
opal_condition_t fl_condition;
|
2005-09-03 23:46:44 +04:00
|
|
|
opal_list_t fl_allocations;
|
This commit brings in two major things:
1. Galen's fine-grain control of queue pair resources in the openib
BTL.
1. Pasha's new implementation of asychronous HCA event handling.
Pasha's new implementation doesn't take much explanation, but the new
"multifrag" stuff does.
Note that "svn merge" was not used to bring this new code from the
/tmp/ib_multifrag branch -- something Bad happened in the periodic
trunk pulls on that branch making an actual merge back to the trunk
effectively impossible (i.e., lots and lots of arbitrary conflicts and
artifical changes). :-(
== Fine-grain control of queue pair resources ==
Galen's fine-grain control of queue pair resources to the OpenIB BTL
(thanks to Gleb for fixing broken code and providing additional
functionality, Pasha for finding broken code, and Jeff for doing all
the svn work and regression testing).
Prior to this commit, the OpenIB BTL created two queue pairs: one for
eager size fragments and one for max send size fragments. When the
use of the shared receive queue (SRQ) was specified (via "-mca
btl_openib_use_srq 1"), these QPs would use a shared receive queue for
receive buffers instead of the default per-peer (PP) receive queues
and buffers. One consequence of this design is that receive buffer
utilization (the size of the data received as a percentage of the
receive buffer used for the data) was quite poor for a number of
applications.
The new design allows multiple QPs to be specified at runtime. Each
QP can be setup to use PP or SRQ receive buffers as well as giving
fine-grained control over receive buffer size, number of receive
buffers to post, when to replenish the receive queue (low water mark)
and for SRQ QPs, the number of outstanding sends can also be
specified. The following is an example of the syntax to describe QPs
to the OpenIB BTL using the new MCA parameter btl_openib_receive_queues:
{{{
-mca btl_openib_receive_queues \
"P,128,16,4;S,1024,256,128,32;S,4096,256,128,32;S,65536,256,128,32"
}}}
Each QP description is delimited by ";" (semicolon) with individual
fields of the QP description delimited by "," (comma). The above
example therefore describes 4 QPs.
The first QP is:
P,128,16,4
Meaning: per-peer receive buffer QPs are indicated by a starting field
of "P"; the first QP (shown above) is therefore a per-peer based QP.
The second field indicates the size of the receive buffer in bytes
(128 bytes). The third field indicates the number of receive buffers
to allocate to the QP (16). The fourth field indicates the low
watermark for receive buffers at which time the BTL will repost
receive buffers to the QP (4).
The second QP is:
S,1024,256,128,32
Shared receive queue based QPs are indicated by a starting field of
"S"; the second QP (shown above) is therefore a shared receive queue
based QP. The second, third and fourth fields are the same as in the
per-peer based QP. The fifth field is the number of outstanding sends
that are allowed at a given time on the QP (32). This provides a
"good enough" mechanism of flow control for some regular communication
patterns.
QPs MUST be specified in ascending receive buffer size order. This
requirement may be removed prior to 1.3 release.
This commit was SVN r15474.
2007-07-18 05:15:59 +04:00
|
|
|
ompi_free_list_item_init_fn_t item_init;
|
|
|
|
void* ctx;
|
2004-06-15 23:46:26 +04:00
|
|
|
};
|
|
|
|
typedef struct ompi_free_list_t ompi_free_list_t;
|
2006-08-24 20:38:08 +04:00
|
|
|
OMPI_DECLSPEC OBJ_CLASS_DECLARATION(ompi_free_list_t);
|
2004-06-15 23:46:26 +04:00
|
|
|
|
2007-03-05 17:17:50 +03:00
|
|
|
struct mca_mpool_base_registration_t;
|
2005-06-07 00:20:47 +04:00
|
|
|
struct ompi_free_list_item_t
|
|
|
|
{
|
2005-07-03 20:22:16 +04:00
|
|
|
opal_list_item_t super;
|
2007-03-05 17:17:50 +03:00
|
|
|
struct mca_mpool_base_registration_t *registration;
|
|
|
|
void *ptr;
|
2005-06-07 00:20:47 +04:00
|
|
|
};
|
|
|
|
typedef struct ompi_free_list_item_t ompi_free_list_item_t;
|
2006-08-24 20:38:08 +04:00
|
|
|
OMPI_DECLSPEC OBJ_CLASS_DECLARATION(ompi_free_list_item_t);
|
2006-06-12 20:44:00 +04:00
|
|
|
|
2004-08-03 01:24:00 +04:00
|
|
|
/**
|
|
|
|
* Initialize a free list.
|
|
|
|
*
|
|
|
|
* @param free_list (IN) Free list.
|
|
|
|
* @param element_size (IN) Size of each element.
|
2005-07-03 20:06:07 +04:00
|
|
|
* @param element_class (IN) opal_class_t of element - used to initialize allocated elements.
|
2004-08-03 01:24:00 +04:00
|
|
|
* @param num_elements_to_alloc Initial number of elements to allocate.
|
|
|
|
* @param max_elements_to_alloc Maximum number of elements to allocate.
|
|
|
|
* @param num_elements_per_alloc Number of elements to grow by per allocation.
|
|
|
|
* @param mpool Optional memory pool for allocation.s
|
|
|
|
*/
|
|
|
|
|
2006-07-20 18:39:05 +04:00
|
|
|
OMPI_DECLSPEC int ompi_free_list_init_ex(
|
2004-08-03 01:24:00 +04:00
|
|
|
ompi_free_list_t *free_list,
|
2004-06-15 23:46:26 +04:00
|
|
|
size_t element_size,
|
2006-07-20 18:39:05 +04:00
|
|
|
size_t alignment,
|
2005-07-03 20:06:07 +04:00
|
|
|
opal_class_t* element_class,
|
2004-06-15 23:46:26 +04:00
|
|
|
int num_elements_to_alloc,
|
|
|
|
int max_elements_to_alloc,
|
|
|
|
int num_elements_per_alloc,
|
This commit brings in two major things:
1. Galen's fine-grain control of queue pair resources in the openib
BTL.
1. Pasha's new implementation of asychronous HCA event handling.
Pasha's new implementation doesn't take much explanation, but the new
"multifrag" stuff does.
Note that "svn merge" was not used to bring this new code from the
/tmp/ib_multifrag branch -- something Bad happened in the periodic
trunk pulls on that branch making an actual merge back to the trunk
effectively impossible (i.e., lots and lots of arbitrary conflicts and
artifical changes). :-(
== Fine-grain control of queue pair resources ==
Galen's fine-grain control of queue pair resources to the OpenIB BTL
(thanks to Gleb for fixing broken code and providing additional
functionality, Pasha for finding broken code, and Jeff for doing all
the svn work and regression testing).
Prior to this commit, the OpenIB BTL created two queue pairs: one for
eager size fragments and one for max send size fragments. When the
use of the shared receive queue (SRQ) was specified (via "-mca
btl_openib_use_srq 1"), these QPs would use a shared receive queue for
receive buffers instead of the default per-peer (PP) receive queues
and buffers. One consequence of this design is that receive buffer
utilization (the size of the data received as a percentage of the
receive buffer used for the data) was quite poor for a number of
applications.
The new design allows multiple QPs to be specified at runtime. Each
QP can be setup to use PP or SRQ receive buffers as well as giving
fine-grained control over receive buffer size, number of receive
buffers to post, when to replenish the receive queue (low water mark)
and for SRQ QPs, the number of outstanding sends can also be
specified. The following is an example of the syntax to describe QPs
to the OpenIB BTL using the new MCA parameter btl_openib_receive_queues:
{{{
-mca btl_openib_receive_queues \
"P,128,16,4;S,1024,256,128,32;S,4096,256,128,32;S,65536,256,128,32"
}}}
Each QP description is delimited by ";" (semicolon) with individual
fields of the QP description delimited by "," (comma). The above
example therefore describes 4 QPs.
The first QP is:
P,128,16,4
Meaning: per-peer receive buffer QPs are indicated by a starting field
of "P"; the first QP (shown above) is therefore a per-peer based QP.
The second field indicates the size of the receive buffer in bytes
(128 bytes). The third field indicates the number of receive buffers
to allocate to the QP (16). The fourth field indicates the low
watermark for receive buffers at which time the BTL will repost
receive buffers to the QP (4).
The second QP is:
S,1024,256,128,32
Shared receive queue based QPs are indicated by a starting field of
"S"; the second QP (shown above) is therefore a shared receive queue
based QP. The second, third and fourth fields are the same as in the
per-peer based QP. The fifth field is the number of outstanding sends
that are allowed at a given time on the QP (32). This provides a
"good enough" mechanism of flow control for some regular communication
patterns.
QPs MUST be specified in ascending receive buffer size order. This
requirement may be removed prior to 1.3 release.
This commit was SVN r15474.
2007-07-18 05:15:59 +04:00
|
|
|
struct mca_mpool_base_module_t*,
|
|
|
|
ompi_free_list_item_init_fn_t item_init,
|
|
|
|
void *ctx
|
|
|
|
);
|
2004-06-15 23:46:26 +04:00
|
|
|
|
2006-07-20 18:39:05 +04:00
|
|
|
static inline int ompi_free_list_init(
|
|
|
|
ompi_free_list_t *free_list,
|
|
|
|
size_t element_size,
|
|
|
|
opal_class_t* element_class,
|
|
|
|
int num_elements_to_alloc,
|
|
|
|
int max_elements_to_alloc,
|
|
|
|
int num_elements_per_alloc,
|
|
|
|
struct mca_mpool_base_module_t* mpool)
|
|
|
|
{
|
2007-03-05 17:17:50 +03:00
|
|
|
return ompi_free_list_init_ex(free_list, element_size, CACHE_LINE_SIZE,
|
2006-07-20 18:39:05 +04:00
|
|
|
element_class, num_elements_to_alloc, max_elements_to_alloc,
|
This commit brings in two major things:
1. Galen's fine-grain control of queue pair resources in the openib
BTL.
1. Pasha's new implementation of asychronous HCA event handling.
Pasha's new implementation doesn't take much explanation, but the new
"multifrag" stuff does.
Note that "svn merge" was not used to bring this new code from the
/tmp/ib_multifrag branch -- something Bad happened in the periodic
trunk pulls on that branch making an actual merge back to the trunk
effectively impossible (i.e., lots and lots of arbitrary conflicts and
artifical changes). :-(
== Fine-grain control of queue pair resources ==
Galen's fine-grain control of queue pair resources to the OpenIB BTL
(thanks to Gleb for fixing broken code and providing additional
functionality, Pasha for finding broken code, and Jeff for doing all
the svn work and regression testing).
Prior to this commit, the OpenIB BTL created two queue pairs: one for
eager size fragments and one for max send size fragments. When the
use of the shared receive queue (SRQ) was specified (via "-mca
btl_openib_use_srq 1"), these QPs would use a shared receive queue for
receive buffers instead of the default per-peer (PP) receive queues
and buffers. One consequence of this design is that receive buffer
utilization (the size of the data received as a percentage of the
receive buffer used for the data) was quite poor for a number of
applications.
The new design allows multiple QPs to be specified at runtime. Each
QP can be setup to use PP or SRQ receive buffers as well as giving
fine-grained control over receive buffer size, number of receive
buffers to post, when to replenish the receive queue (low water mark)
and for SRQ QPs, the number of outstanding sends can also be
specified. The following is an example of the syntax to describe QPs
to the OpenIB BTL using the new MCA parameter btl_openib_receive_queues:
{{{
-mca btl_openib_receive_queues \
"P,128,16,4;S,1024,256,128,32;S,4096,256,128,32;S,65536,256,128,32"
}}}
Each QP description is delimited by ";" (semicolon) with individual
fields of the QP description delimited by "," (comma). The above
example therefore describes 4 QPs.
The first QP is:
P,128,16,4
Meaning: per-peer receive buffer QPs are indicated by a starting field
of "P"; the first QP (shown above) is therefore a per-peer based QP.
The second field indicates the size of the receive buffer in bytes
(128 bytes). The third field indicates the number of receive buffers
to allocate to the QP (16). The fourth field indicates the low
watermark for receive buffers at which time the BTL will repost
receive buffers to the QP (4).
The second QP is:
S,1024,256,128,32
Shared receive queue based QPs are indicated by a starting field of
"S"; the second QP (shown above) is therefore a shared receive queue
based QP. The second, third and fourth fields are the same as in the
per-peer based QP. The fifth field is the number of outstanding sends
that are allowed at a given time on the QP (32). This provides a
"good enough" mechanism of flow control for some regular communication
patterns.
QPs MUST be specified in ascending receive buffer size order. This
requirement may be removed prior to 1.3 release.
This commit was SVN r15474.
2007-07-18 05:15:59 +04:00
|
|
|
num_elements_per_alloc, mpool, NULL, NULL);
|
2006-07-20 18:39:05 +04:00
|
|
|
}
|
|
|
|
|
2007-11-01 20:25:12 +03:00
|
|
|
/**
|
|
|
|
* Initialize a free list. - this will replace ompi_free_list_init_ex
|
|
|
|
*
|
|
|
|
* @param free_list (IN) Free list.
|
|
|
|
* @param frag_size (IN) Size of each element - allocated by malloc.
|
|
|
|
* @param frag_alignment (IN) Fragment alignment.
|
|
|
|
* @param frag_class (IN) opal_class_t of element - used to initialize allocated elements.
|
|
|
|
* @param payload_buffer_size (IN) Size of payload buffer - allocated from mpool.
|
|
|
|
* @param payload_buffer_alignment (IN) Payload buffer alignment.
|
|
|
|
* @param num_elements_to_alloc (IN) Initial number of elements to allocate.
|
|
|
|
* @param max_elements_to_alloc (IN) Maximum number of elements to allocate.
|
|
|
|
* @param num_elements_per_alloc (IN) Number of elements to grow by per allocation.
|
|
|
|
* @param mpool (IN) Optional memory pool for allocation.s
|
|
|
|
* @param item_init (IN)
|
|
|
|
* @param ctx (IN)
|
|
|
|
*/
|
|
|
|
|
|
|
|
OMPI_DECLSPEC int ompi_free_list_init_ex_new(
|
|
|
|
ompi_free_list_t *free_list,
|
|
|
|
size_t frag_size,
|
|
|
|
size_t frag_alignment,
|
|
|
|
opal_class_t* frag_class,
|
|
|
|
size_t payload_buffer_size,
|
|
|
|
size_t payload_buffer_alignment,
|
|
|
|
int num_elements_to_alloc,
|
|
|
|
int max_elements_to_alloc,
|
|
|
|
int num_elements_per_alloc,
|
|
|
|
struct mca_mpool_base_module_t*,
|
|
|
|
ompi_free_list_item_init_fn_t item_init,
|
|
|
|
void *ctx
|
|
|
|
);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Initialize a free list. - this will replace ompi_free_list_init
|
|
|
|
*
|
|
|
|
* @param free_list (IN) Free list.
|
|
|
|
* @param frag_size (IN) Size of each element - allocated by malloc.
|
|
|
|
* @param frag_alignment (IN) Fragment alignment.
|
|
|
|
* @param frag_class (IN) opal_class_t of element - used to initialize allocated elements.
|
|
|
|
* @param payload_buffer_size (IN) Size of payload buffer - allocated from mpool.
|
|
|
|
* @param payload_buffer_alignment (IN) Payload buffer alignment.
|
|
|
|
* @param num_elements_to_alloc (IN) Initial number of elements to allocate.
|
|
|
|
* @param max_elements_to_alloc (IN) Maximum number of elements to allocate.
|
|
|
|
* @param num_elements_per_alloc (IN) Number of elements to grow by per allocation.
|
|
|
|
* @param mpool (IN) Optional memory pool for allocation.s
|
|
|
|
*/
|
|
|
|
static inline int ompi_free_list_init_new(
|
|
|
|
ompi_free_list_t *free_list,
|
|
|
|
size_t frag_size,
|
|
|
|
size_t frag_alignment,
|
|
|
|
opal_class_t* frag_class,
|
|
|
|
size_t payload_buffer_size,
|
|
|
|
size_t payload_buffer_alignment,
|
|
|
|
int num_elements_to_alloc,
|
|
|
|
int max_elements_to_alloc,
|
|
|
|
int num_elements_per_alloc,
|
|
|
|
struct mca_mpool_base_module_t* mpool)
|
|
|
|
{
|
|
|
|
return ompi_free_list_init_ex_new(free_list,
|
|
|
|
frag_size, frag_alignment, frag_class,
|
|
|
|
payload_buffer_size, payload_buffer_alignment,
|
|
|
|
num_elements_to_alloc, max_elements_to_alloc,
|
|
|
|
num_elements_per_alloc, mpool, NULL, NULL);
|
|
|
|
}
|
2006-07-20 18:39:05 +04:00
|
|
|
|
2004-10-28 22:13:43 +04:00
|
|
|
OMPI_DECLSPEC int ompi_free_list_grow(ompi_free_list_t* flist, size_t num_elements);
|
2006-04-20 23:53:45 +04:00
|
|
|
|
2006-10-10 18:47:51 +04:00
|
|
|
/* Grow the free list to be *at least* size elements. This function
|
2006-10-07 01:13:49 +04:00
|
|
|
will not shrink the list if it is already larger than size and may
|
|
|
|
grow it past size if necessary (it will grow in
|
|
|
|
num_elements_per_alloc chunks) */
|
|
|
|
OMPI_DECLSPEC int ompi_free_list_resize(ompi_free_list_t *flist, size_t size);
|
|
|
|
|
2006-04-20 23:53:45 +04:00
|
|
|
/* Allow to walk through the all allocated items. Not thread-safe, not
|
|
|
|
* protected, this function should never be used except for debugging purposes.
|
|
|
|
* The position should never be NULL, and it should be set to {NULL, NULL}
|
|
|
|
* for the first call.
|
|
|
|
*/
|
|
|
|
typedef struct ompi_free_list_pos_t {
|
|
|
|
unsigned char* last_memory;
|
|
|
|
unsigned char* last_item;
|
|
|
|
} ompi_free_list_pos_t;
|
2007-02-06 15:00:30 +03:00
|
|
|
#define OMPI_FREE_LIST_POS_BEGINNING {NULL, NULL}
|
2006-04-20 23:53:45 +04:00
|
|
|
|
|
|
|
OMPI_DECLSPEC int ompi_free_list_parse( ompi_free_list_t* list,
|
|
|
|
ompi_free_list_pos_t* position,
|
|
|
|
opal_list_item_t** return_item );
|
2004-08-03 01:24:00 +04:00
|
|
|
/**
|
|
|
|
* Attemp to obtain an item from a free list.
|
|
|
|
*
|
|
|
|
* @param fl (IN) Free list.
|
|
|
|
* @param item (OUT) Allocated item.
|
|
|
|
* @param rc (OUT) OMPI_SUCCESS or error status on failure.
|
|
|
|
*
|
|
|
|
* If the requested item is not available the free list is grown to
|
|
|
|
* accomodate the request - unless the max number of allocations has
|
|
|
|
* been reached. If this is the case - an out of resource error is
|
|
|
|
* returned to the caller.
|
|
|
|
*/
|
|
|
|
|
2004-06-15 23:46:26 +04:00
|
|
|
#define OMPI_FREE_LIST_GET(fl, item, rc) \
|
|
|
|
{ \
|
2007-07-06 02:47:31 +04:00
|
|
|
rc = OMPI_SUCCESS; \
|
|
|
|
item = (ompi_free_list_item_t*) opal_atomic_lifo_pop(&((fl)->super)); \
|
2008-01-15 08:44:28 +03:00
|
|
|
if( OPAL_UNLIKELY(NULL == item) ) { \
|
2007-07-06 02:47:31 +04:00
|
|
|
if(opal_using_threads()) { \
|
2006-04-13 03:27:38 +04:00
|
|
|
opal_mutex_lock(&((fl)->fl_lock)); \
|
2004-06-15 23:46:26 +04:00
|
|
|
ompi_free_list_grow((fl), (fl)->fl_num_per_alloc); \
|
2006-04-13 03:27:38 +04:00
|
|
|
opal_mutex_unlock(&((fl)->fl_lock)); \
|
2007-07-06 02:47:31 +04:00
|
|
|
} else { \
|
2004-06-15 23:46:26 +04:00
|
|
|
ompi_free_list_grow((fl), (fl)->fl_num_per_alloc); \
|
|
|
|
} \
|
2007-07-06 02:47:31 +04:00
|
|
|
item = (ompi_free_list_item_t*) opal_atomic_lifo_pop(&((fl)->super)); \
|
2008-01-15 08:44:28 +03:00
|
|
|
if( OPAL_UNLIKELY(NULL == item) ) rc = OMPI_ERR_TEMP_OUT_OF_RESOURCE; \
|
2004-06-15 23:46:26 +04:00
|
|
|
} \
|
|
|
|
}
|
|
|
|
|
2004-08-03 01:24:00 +04:00
|
|
|
/**
|
|
|
|
* Blocking call to obtain an item from a free list.
|
|
|
|
*
|
|
|
|
* @param fl (IN) Free list.
|
|
|
|
* @param item (OUT) Allocated item.
|
|
|
|
* @param rc (OUT) OMPI_SUCCESS or error status on failure.
|
|
|
|
*
|
|
|
|
* If the requested item is not available the free list is grown to
|
|
|
|
* accomodate the request - unless the max number of allocations has
|
|
|
|
* been reached. In this case the caller is blocked until an item
|
|
|
|
* is returned to the list.
|
|
|
|
*/
|
2004-06-15 23:46:26 +04:00
|
|
|
|
2006-01-14 01:02:40 +03:00
|
|
|
#define OMPI_FREE_LIST_WAIT(fl, item, rc) \
|
2006-06-13 02:09:03 +04:00
|
|
|
rc = __ompi_free_list_wait( (fl), &(item) )
|
2004-07-15 22:08:20 +04:00
|
|
|
|
2006-04-13 03:27:38 +04:00
|
|
|
static inline int __ompi_free_list_wait( ompi_free_list_t* fl,
|
|
|
|
ompi_free_list_item_t** item )
|
|
|
|
{
|
|
|
|
*item = (ompi_free_list_item_t*)opal_atomic_lifo_pop(&((fl)->super));
|
|
|
|
while( NULL == *item ) {
|
2006-05-17 03:13:48 +04:00
|
|
|
if( !OPAL_THREAD_TRYLOCK(&((fl)->fl_lock)) ) {
|
2006-04-13 03:27:38 +04:00
|
|
|
if((fl)->fl_max_to_alloc <= (fl)->fl_num_allocated) {
|
|
|
|
(fl)->fl_num_waiting++;
|
|
|
|
opal_condition_wait(&((fl)->fl_condition), &((fl)->fl_lock));
|
|
|
|
(fl)->fl_num_waiting--;
|
|
|
|
} else {
|
2006-06-27 13:23:51 +04:00
|
|
|
if(ompi_free_list_grow((fl), (fl)->fl_num_per_alloc)
|
|
|
|
== OMPI_SUCCESS) {
|
|
|
|
if( 0 < (fl)->fl_num_waiting ) {
|
2006-10-06 20:17:50 +04:00
|
|
|
if( 1 == (fl)->fl_num_waiting ) {
|
|
|
|
opal_condition_signal(&((fl)->fl_condition));
|
|
|
|
} else {
|
|
|
|
opal_condition_broadcast(&((fl)->fl_condition));
|
|
|
|
}
|
2006-06-27 13:23:51 +04:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
(fl)->fl_num_waiting++;
|
|
|
|
opal_condition_wait(&((fl)->fl_condition), &((fl)->fl_lock));
|
|
|
|
(fl)->fl_num_waiting--;
|
2006-04-13 03:27:38 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/* If I wasn't able to get the lock in the begining when I finaly grab it
|
|
|
|
* the one holding the lock in the begining already grow the list. I will
|
|
|
|
* release the lock and try to get a new element until I succeed.
|
|
|
|
*/
|
|
|
|
OPAL_THREAD_LOCK(&((fl)->fl_lock));
|
|
|
|
}
|
|
|
|
OPAL_THREAD_UNLOCK(&((fl)->fl_lock));
|
|
|
|
*item = (ompi_free_list_item_t*)opal_atomic_lifo_pop(&((fl)->super));
|
|
|
|
}
|
|
|
|
return OMPI_SUCCESS;
|
|
|
|
}
|
2004-07-15 22:08:20 +04:00
|
|
|
|
2004-08-03 01:24:00 +04:00
|
|
|
/**
|
|
|
|
* Return an item to a free list.
|
|
|
|
*
|
|
|
|
* @param fl (IN) Free list.
|
|
|
|
* @param item (OUT) Allocated item.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2006-04-13 03:27:38 +04:00
|
|
|
#define OMPI_FREE_LIST_RETURN(fl, item) \
|
|
|
|
do { \
|
|
|
|
opal_list_item_t* original; \
|
|
|
|
\
|
|
|
|
original = opal_atomic_lifo_push( &(fl)->super, \
|
2006-06-13 02:09:03 +04:00
|
|
|
&(item)->super); \
|
2006-04-13 03:27:38 +04:00
|
|
|
if( &(fl)->super.opal_lifo_ghost == original ) { \
|
|
|
|
OPAL_THREAD_LOCK(&(fl)->fl_lock); \
|
|
|
|
if((fl)->fl_num_waiting > 0) { \
|
2006-10-06 20:17:50 +04:00
|
|
|
if( 1 == (fl)->fl_num_waiting ) { \
|
|
|
|
opal_condition_signal(&((fl)->fl_condition)); \
|
|
|
|
} else { \
|
|
|
|
opal_condition_broadcast(&((fl)->fl_condition)); \
|
|
|
|
} \
|
2006-04-13 03:27:38 +04:00
|
|
|
} \
|
|
|
|
OPAL_THREAD_UNLOCK(&(fl)->fl_lock); \
|
|
|
|
} \
|
|
|
|
} while(0)
|
|
|
|
|
2004-10-21 02:31:03 +04:00
|
|
|
#if defined(c_plusplus) || defined(__cplusplus)
|
|
|
|
}
|
|
|
|
#endif
|
2004-06-15 23:46:26 +04:00
|
|
|
#endif
|
|
|
|
|