Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

From: Bert Wesarg (wesarg_at_[hidden])
Date: 2007-03-06 12:22:12


Hello,

this gives the option to use the umem cache feature from the libumem[1]
for the opal object system.

It is full backward compatible to the old system.

But the patch exists of more changes:

(1) reorder opal_class_t, in the hope that vital members fit in the first
    cache line
(2) a per class lock for initialization
(3) the global class list is now a linked list embeded in the opal_class_t
    (this can be reduced to a stack/single linked list)
(4) new contructors/destructors for the one time cache initialization

To complile with this new feature you must configure open-mpi with
"-DUSE_UMEM" in your CFLAGS, and all other needed build flags to find the
header and library of lubumem (LDFLAGS, LIBS).

To full use the object caching of libumem you can use the new macro
OBJ_CLASS_INSTANCE_CACHE() which have arguments for the cache
contructors/destructors.

In the followup mail, I convert the opal_free_list_t and
orte_pointer_array_t to use the cache for the initialization of the
opal_mutex_t and opal_condition_t members.

I have just compiled it with and without USE_UMEM but no benchmarking.

Comments welcome.

Greetings

Bert Wesarg

PS: I know that you are busy with the OMPI 1.2 release, I just want to
send it out, befor I forget it.

[1] solaris: built-in
    other: http://sourceforge.net/projects/umem