Re: [OMPI devel] OMPI devel] [OMPI commits] Git: open-mpi/ompi branch master updated. dev-198-g68bec0a
Hi Dave,
I am sorry about that, the doc is not to be blamed here.
I usually do pull/commit/push in a row to avoid this kind of things but i
screwed up this time ...
I cannot remember if i did commit/pull/push or if i simply forgot to pull
btw, is there a push option to abort if that would make github history non
linear ?
Cheers,
Gilles
"Dave Goodell (dgoodell)" wrote:
>Hi Gilles,
>
>Please try to avoid creating merge-of-master commits like 68bec0ae ("Merge
>branch 'master' of..."), they just clutter the history. A rebase is almost
>always more appropriate in this situation.
>
>https://github.com/open-mpi/ompi/wiki/GitBestPractices
>
>If you created that commit with "git pull", you can perform the rebase
>equivalent by running "git pull --rebase". If this doesn't make sense, just
>let me know and I can explain further and/or improve the docs around this.
>
>Thanks,
>-Dave
>
>On Oct 31, 2014, at 2:35 AM, git...@crest.iu.edu wrote:
>
>> This is an automated email from the git hooks/post-receive script. It was
>> generated because a ref change was pushed to the repository containing
>> the project "open-mpi/ompi".
>>
>> The branch, master has been updated
>> via 68bec0ae1f022e095c132b3f8c7317238b318416 (commit)
>> via 76ee98c86a7dafc922d342bc4c819ecc3ee14f52 (commit)
>> from 672d96704cc165b91c7bcf263e97704affcd5f20 (commit)
>>
>> Those revisions listed above that are new to this repository have
>> not appeared on any other notification email; so we list those
>> revisions in full, below.
>>
>> - Log -
>> https://github.com/open-mpi/ompi/commit/68bec0ae1f022e095c132b3f8c7317238b318416
>>
>> commit 68bec0ae1f022e095c132b3f8c7317238b318416
>> Merge: 76ee98c 672d967
>> Author: Gilles Gouaillardet
>> Date: Fri Oct 31 16:34:43 2014 +0900
>>
>>Merge branch 'master' of https://github.com/open-mpi/ompi
>>
>>
>>
>> https://github.com/open-mpi/ompi/commit/76ee98c86a7dafc922d342bc4c819ecc3ee14f52
>>
>> commit 76ee98c86a7dafc922d342bc4c819ecc3ee14f52
>> Author: Gilles Gouaillardet
>> Date: Fri Oct 31 16:34:02 2014 +0900
>>
>>btl/scif: start the listening thread once only
>>
>> diff --git a/opal/mca/btl/scif/btl_scif.h b/opal/mca/btl/scif/btl_scif.h
>> index 741fda8..b8d9aab 100644
>> --- a/opal/mca/btl/scif/btl_scif.h
>> +++ b/opal/mca/btl/scif/btl_scif.h
>> @@ -93,6 +93,7 @@ typedef struct mca_btl_scif_module_t {
>> pthread_t listen_thread;
>>
>> volatile bool exiting;
>> +bool listening;
>> } mca_btl_scif_module_t;
>>
>> typedef struct mca_btl_scif_component_t {
>> diff --git a/opal/mca/btl/scif/btl_scif_add_procs.c
>> b/opal/mca/btl/scif/btl_scif_add_procs.c
>> index 80da884..4a6d838 100644
>> --- a/opal/mca/btl/scif/btl_scif_add_procs.c
>> +++ b/opal/mca/btl/scif/btl_scif_add_procs.c
>> @@ -98,10 +98,13 @@ int mca_btl_scif_add_procs(struct mca_btl_base_module_t*
>> btl,
>>
>> scif_module->endpoint_count = procs_on_board;
>>
>> -/* start listening thread */
>> -rc = pthread_create (&mca_btl_scif_module.listen_thread, NULL,
>> mca_btl_scif_connect_accept, NULL);
>> -if (0 > rc) {
>> -return OPAL_ERROR;
>> +if (!mca_btl_scif_module.listening) {
>> +/* start listening thread */
>> +rc = pthread_create (&mca_btl_scif_module.listen_thread, NULL,
>> mca_btl_scif_connect_accept, NULL);
>> +if (0 > rc) {
>> +return OPAL_ERROR;
>> +}
>> +mca_btl_scif_module.listening = true;
>> }
>>
>> return OPAL_SUCCESS;
>> diff --git a/opal/mca/btl/scif/btl_scif_component.c
>> b/opal/mca/btl/scif/btl_scif_component.c
>> index 7600b12..61bf2d1 100644
>> --- a/opal/mca/btl/scif/btl_scif_component.c
>> +++ b/opal/mca/btl/scif/btl_scif_component.c
>> @@ -267,6 +267,7 @@ static mca_btl_base_module_t
>> **mca_btl_scif_component_init (int *num_btl_modules
>>
>> base_modules[0] = &mca_btl_scif_module.super;
>> mca_btl_scif_module.exiting = false;
>> +mca_btl_scif_module.listening = false;
>>
>> rc = mca_btl_scif_modex_send ();
>> if (OPAL_SUCCESS != rc) {
>> diff --git a/opal/mca/btl/scif/btl_scif_module.c
>> b/opal/mca/btl/scif/btl_scif_module.c
>> index cfb..fb36b7b 100644
>> --- a/opal/mca/btl/scif/btl_scif_module.c
>> +++ b/opal/mca/btl/scif/btl_scif_module.c
>> @@ -126,7 +126,7 @@ mca_btl_scif_module_finalize (struct
>> mca_btl_base_module_t *btl)
>> }
>>
>> /* close the listening endpoint */
>> -if (-1 != mca_btl_scif_module.scif_fd) {
>> +if (mca_btl_scif_module.listening && -1 != mca_btl_scif_module.scif_fd)
>> {
>> /* wake up the scif thread */
>> scif_epd_t tmpfd;
>> tmpfd = scif_open();
>>
>>
>> ---
>>
>> Summary of changes:
>> opal/mca/btl/scif/btl_scif.h | 1 +
>> opal/mca/btl/scif/btl_scif_add_procs.c | 11 +++
>> opal/mca/btl/scif/btl_scif_component.c
Re: [OMPI devel] OMPI devel] [OMPI commits] Git: open-mpi/ompi branch master updated. dev-198-g68bec0a
On Nov 1, 2014, at 4:44 AM, Gilles Gouaillardet wrote: > I am sorry about that, the doc is not to be blamed here. > I usually do pull/commit/push in a row to avoid this kind of things but i > screwed up this time ... > I cannot remember if i did commit/pull/push or if i simply forgot to pull FWIW, to avoid this kind of stuff, I usually do the following: - $ cat ~/.gitconfig [user] name = Jeff Squyres email = jsquy...@cisco.com [alias] pr = pull --rebase ...etc. - I then always use "git pr" instead of "git pull". > btw, is there a push option to abort if that would make github history non > linear ? I'm not aware of one. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] enable-smp-locks affects PSM performance
Andrew -- A PR went in on the v1.8 branch that removed the locking behavior by default: https://github.com/open-mpi/ompi-release/pull/67 Can you confirm that the behavior on the v1.8 nightly tarballs show better PSM message rate behavior? (http://www.open-mpi.org/nightly/v1.8/ -- 135 and beyond have the fix) For master, this was actually the exactly intended result: at a previous OMPI dev meeting, we said "let's turn on threading, and see who screams." You screamed. :-) In a conversation with Nathan on Friday, it looks like many things in 6ef938de3fa9ca0fed2c5bcb0736f65b0d8803af get more expensive with threading enabled -- particularly freelists. It's quite possible that we should change many of these things to be more expensive only a) if THREAD_MULTIPLE is active, and/or b) if progress threads are active. However, that may not be safe in itself. Perhaps we should have multiple flavors of these types (like freelists) that are both thread safe and thread unsafe. So even if we're in a THREAD_MULTIPLE and/or progress threads are active, if you *know* you've got a data structure that does not need the added thread-safety protections, you can use the unsafe-but-faster versions. On Oct 30, 2014, at 12:51 PM, Friedley, Andrew wrote: > Hi Howard, > > No, we do not, just the OMPI default. > > This post isn’t so much about our packaging requirements, as about default > behavior in upstream Open MPI. We’d like performance to be good by default > for anyone compiling their own Open MPI (and using PSM). > > Andrew > > From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Howard Pritchard > Sent: Thursday, October 30, 2014 8:53 AM > To: Open MPI Developers > Subject: Re: [OMPI devel] enable-smp-locks affects PSM performance > > Hi Andrew, > > In your distribution of ompi, do you include versions of ompi to support > different MPI thread safetylevels? In particular, do you include a library > which supports MPI_THREAD_MULTIPLE? > Just trying to better understand the requirements of you ompi package in > terms of MPI thread safety. > > Thanks, > > Howard > > > 2014-10-30 8:10 GMT-06:00 Friedley, Andrew : > Hi, > > I'm reporting a performance (message rate 16%, latency 3%) regression when > using PSM that occurred between OMPI v1.6.5 and v1.8.1. I would guess it > affects other networks too, but I haven't tested. The problem stems from the > --enable-smp-locks and --enable-opal-multi-threads options. > > --enable-smp-locks defaults to enabled and, on x86, causes a 'lock' prefix to > be prepended to ASM instructions used by atomic primitives. Disabling > removes the 'lock' prefix. > > In OMPI 1.6.5, --enable-opal-multi-threads defaulted to disabled. When > enabled, OPAL would be compiled with multithreading support, which included > compiling in calls to atomic primitives. Those atomic primitives, in turn, > potentially use a lock prefix (controlled by --enable-smp-locks). > > SVN r29891 on the trunk changed the above. --enable-opal-multi-threads was > removed. CPP macros (#if OPAL_ENABLE_MULTI_THREADS) controlling various > calls to atomic primitives were removed, effectively changing the default > behavior to multithreading ON for OPAL. This change was then carried to the > v1.7 branch in r29944, Fixes #3983. > > We can use --disable-smp-locks to make the performance regression go away for > the builds we ship, but we'd very much prefer if performance was good 'out of > the box' for people that grab an OMPI tarball and use it with PSM. > > My question is, what's the best way to do that? It seems obvious to just > make --disable-smp-locks the default, but I presume the change was done on > purpose, so I'm looking for community feedback. > > Thanks, > > Andrew > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/10/16130.php > > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/10/16133.php -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
