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.
On Nov 22, 2010, at 11:35 AM, Barrett, Brian W wrote:
> Um, the counter starts initialized at one.
Does that mean that we should or should not leave that extra _decrement() in there?
> On Nov 22, 2010, at 9:32 AM, Jeff Squyres wrote:
>> A user noticed a specific change that we made between 1.4.2 and 1.4.3:
>> which is from CMR https://svn.open-mpi.org/trac/ompi/ticket/2489, and originally from trunk https://svn.open-mpi.org/trac/ompi/changeset/23434. I removed the opal_progress_event_users_decrement() from ompi_mpi_init() because the ORTE DPM does its own _increment() and _decrement().
>> However, it seems that there was an unintended consequence of this -- look at the annotated Ganglia graph that the user sent (see attached). In 1.4.2, all of the idle time was "user" CPU usage. In 1.4.3, it's split between user and system CPU usage. The application that he used to test is basically an init / finalize test (with some additional MPI middleware). See:
>> Can anyone think of why this occurs, and/or if it's a Bad Thing?
>> If removing this decrement enabled a bunch more system CPU time, that would seem to imply that we're calling libevent more frequently than we used to (vs. polling the opal event callbacks), and therefore that there might now be an unmatched increment somewhere.
>> Jeff Squyres
>> For corporate legal information go to:
> Brian W. Barrett
> Dept. 1423: Scalable System Software
> Sandia National Laboratories
> devel mailing list
For corporate legal information go to: