Re: [OMPI devel] RFC: remove --disable-smp-locks
Added to the wiki / agenda. On Jan 7, 2015, at 11:35 AM, Nathan Hjelm wrote: > > I think this is a good discussion for the Dallas meeting. We can hold > off on this RFC until then. > > -Nathan > > On Tue, Jan 06, 2015 at 06:16:39PM -0500, George Bosilca wrote: >> On Tue, Jan 6, 2015 at 4:25 PM, Jeff Squyres (jsquyres) >>wrote: >> >> My enthusiasm for this was primarily because I thought we had talked >> about exactly this issue before (at the last meeting in Chicago?), and >> decided that the option is useless -- in part, because it always *must* >> be enabled for shared memory correctness. >> >> Is that incorrect? >> >> This is correct. We need the memory fences and atomic operations for >> shared memory in all cases. When thread support is enabled we also need >> them in various other places. However, this option also turns on the lock >> prefix for the atomic operations, forcing them to always be atomic. I am >> not sure that this has no unexpected side-effects on the code. >> George. >> >> >> On Jan 6, 2015, at 4:12 PM, George Bosilca wrote: >> >>> Successive alteration of the build system made this option less >> relevant and especially less meaningful. However, while removing it >> sounds like a desirable cleanup, we have to keep in mind that this will >> enable all locks and all memory barriers even in cases where they are >> not necessary (via OPAL_WANT_SMP_LOCKS). >>> >>> Thus, I do not share the enthusiasm of the others. I would prefer to >> see an evaluation of the impact on performance, a patch and a little bit >> more than 1/2 a day to react to it (the proposed deadline seems to be >> today January 6th) before such a drastic change. >>> >>> George. >>> >>> >>> On Tue, Jan 6, 2015 at 12:05 PM, Ralph Castain >> wrote: >>> +1 >>> On Jan 6, 2015, at 9:04 AM, Jeff Squyres (jsquyres) >> wrote: +1 On Jan 6, 2015, at 11:55 AM, Howard Pritchard >> wrote: > I agree. Please remove this config option. > > 2015-01-06 9:44 GMT-07:00 Nathan Hjelm : > > What: Remove the --disable-smp-locks configure option from master. > > Why: Use of this option produces incorrect results/undefined >> behavior > when any shared memory BTL is in use. Since BTL usage is enabled >> even > when using cm for point-to-point this option can never be safely >> used. > > When: Thurs, Jan 6, 2015 > > -Nathan > > ___ > 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/2015/01/16736.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/2015/01/16737.php -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ ___ 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/2015/01/16739.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/2015/01/16740.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/2015/01/16741.php >> >> -- >> Jeff Squyres >> jsquy...@cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> ___ >> 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/2015/01/16742.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/2015/01/16743.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/2
Re: [OMPI devel] pthreads (was: Re: RFC: remove --disable-smp-locks)
See note on other thread as to why we made the pthread decision > On Jan 7, 2015, at 8:30 AM, Jeff Squyres (jsquyres) > wrote: > > Ok. Then I'm good with Gilles' plan. > > Anyone else? > > > On Jan 7, 2015, at 11:29 AM, Nathan Hjelm wrote: > >> >> Yes, we decided some time back that pthreads is a minimum requirement >> for Open MPI. >> >> -Nathan >> >> On Wed, Jan 07, 2015 at 04:26:01PM +, Jeff Squyres (jsquyres) wrote: >>> On Jan 7, 2015, at 11:22 AM, Gilles Gouaillardet >>> wrote: >>> Valid options are : --with-threads e.g. --with-threads=posix e.g. default And --with-threads=no Except configure will explicitly fail if --with-threads=no is used >>> >>> Which is the moral equivalent of not having this option. :-) (which I >>> think is your point :-) ) >>> So bottom line, pthreads and pthreads only are usable >>> >>> But my question remains: we all decided that OMPI will *require* pthreads, >>> right? (i.e., configure will fail if pthreads are not available) >>> >>> I am being pedantic here, I know -- but it's slightly different than what >>> you're saying, and this threading stuff is already quite confusing... >>> >>> Cheers, Gilles "Jeff Squyres (jsquyres)" さんのメール: > On Jan 7, 2015, at 4:25 AM, Gilles Gouaillardet > wrote: > >> Talking about thread support ... >> >> i made a RFC several monthes ago in order to remove the >> --with-threads option from configure >> >> /* ompi requires pthreads, no more, no less */ > > Did we decide this? (that OMPI *requires* pthreads) > > I *think* we did. But I just want to make sure that my (terrible) memory > is correct... > >> it was accepted, but i could not find the time to implement it ... >> >> basically, i can see three steps : >> >> 1) remove the --with-threads option from configure, check for pthreads, >> and set the >> OPAL_HAVE_POSIX_THREADS macro to 1 > > Sounds good. > >> 2) step 1) + remove #ifdef OPAL_HAVE_POSIX_THREADS and remove dead code >> (e.g. #ifndef OPAL_HAVE_POSIX_THREADS) > > Also make configure fail if pthreads are not available. > >> 3) step 1) + step 2) + remove the OPAL thread abstraction layer >> >> is it a good idea to implement steps 2) and 3) ? >> i mean, if there is a chance we might support an other threading model >> in the future, >> it might be better to keep some dead code for the time being. > > I think the consensus was that pthreads are fine for the foreseeable > future. If we need to re-add the threading abstraction layer, it's > annoying, but not difficult. Might as well simplify what we have, since > there's no other threading system on the horizon that we need to worry > about. > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > ___ > 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/2015/01/16750.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/2015/01/16751.php >>> >>> >>> -- >>> Jeff Squyres >>> jsquy...@cisco.com >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> ___ >>> 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/2015/01/16752.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/2015/01/16753.php > > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > ___ > 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/2015/01/16754.php
Re: [OMPI devel] pthreads (was: Re: RFC: remove --disable-smp-locks)
> On Jan 7, 2015, at 8:13 AM, Jeff Squyres (jsquyres) > wrote: > > On Jan 7, 2015, at 4:25 AM, Gilles Gouaillardet > wrote: > >> Talking about thread support ... >> >> i made a RFC several monthes ago in order to remove the >> --with-threads option from configure >> >> /* ompi requires pthreads, no more, no less */ > > Did we decide this? (that OMPI *requires* pthreads) > > I *think* we did. But I just want to make sure that my (terrible) memory is > correct… I believe we did - at least, we require that libevent be thread-enabled, and that means it definitely requires pthreads. Since that component is statically built, that pull the pthread lib into the ompi lib anyway, so I see no problem in “requiring” it. > >> it was accepted, but i could not find the time to implement it ... >> >> basically, i can see three steps : >> >> 1) remove the --with-threads option from configure, check for pthreads, and >> set the >> OPAL_HAVE_POSIX_THREADS macro to 1 > > Sounds good. > >> 2) step 1) + remove #ifdef OPAL_HAVE_POSIX_THREADS and remove dead code >> (e.g. #ifndef OPAL_HAVE_POSIX_THREADS) > > Also make configure fail if pthreads are not available. > >> 3) step 1) + step 2) + remove the OPAL thread abstraction layer >> >> is it a good idea to implement steps 2) and 3) ? >> i mean, if there is a chance we might support an other threading model in >> the future, >> it might be better to keep some dead code for the time being. > > I think the consensus was that pthreads are fine for the foreseeable future. > If we need to re-add the threading abstraction layer, it's annoying, but not > difficult. Might as well simplify what we have, since there's no other > threading system on the horizon that we need to worry about. > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > ___ > 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/2015/01/16750.php
Re: [OMPI devel] ompi-master build error : make can require autotools
I think that makes sense. I checked and my CentOS box is actually using 1.12.4 and seems to be fine. I can update it though and probably should. FWIW: good to remember that this problem only *can* occur - it doesn’t always happen, and it seems to require some unusual steps to trigger it. So I don’t think it’s necessary to change anything in 1.8 as we can legitimately say “don’t do that”. > On Jan 7, 2015, at 6:43 AM, Jeff Squyres (jsquyres) > wrote: > > On Jan 6, 2015, at 9:52 PM, Ralph Castain wrote: > >> The 1.12 series had a set of problems caused by a changeover in the >> maintainers, so it should never be used. I’m not sure if any of those issues >> are behind this problem, but it could be so. >> >> Anyway, I think pretty much all of us are using automake 1.14 by this time. >> We can discuss how far up to move the requirement, but I think 1.14 would be >> the right place. > > Fair enough. > > I don't think we should change the set used to generate 1.8 series tarballs, > though. I think it's a good policy to keep the same autotools tuple for the > entire series, unless there's a good reason to change. > > As Dave noted, our default on our Cisco dev cluster is AM 1.13.3. Probably > just because that was the most recent version when we last did maintenance on > our AM toolchain. It's easy enough for us to update, though. > > Another point would probably be to update > http://www.open-mpi.org/source/building.php to say that the versions listed > for master are a minimum version -- devs can use whatever they want (that > works :-) ). The other table lines list what tuple is used to create those > tarballs. > > Also note that per https://github.com/open-mpi/ompi/issues/311, we cannot > upgrade past LT 2.4.2 right now. This looks like a bug in LT itself (not > OMPI), but I don't have a workaround/solution to go beyond LT 2.4.2 right now > (and I think it's not high priority... yet). > > In conclusion: I'll bump the AM version for master on building.php to be > 1.13.3 because I know for a fact that it works. If we want to move it higher > than that, I don't have too strong an opinion. :-) I think all the other > versions for master are fine. > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > ___ > 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/2015/01/16748.php
Re: [OMPI devel] RFC: remove --disable-smp-locks
I think this is a good discussion for the Dallas meeting. We can hold off on this RFC until then. -Nathan On Tue, Jan 06, 2015 at 06:16:39PM -0500, George Bosilca wrote: >On Tue, Jan 6, 2015 at 4:25 PM, Jeff Squyres (jsquyres) > wrote: > > My enthusiasm for this was primarily because I thought we had talked > about exactly this issue before (at the last meeting in Chicago?), and > decided that the option is useless -- in part, because it always *must* > be enabled for shared memory correctness. > > Is that incorrect? > >This is correct. We need the memory fences and atomic operations for >shared memory in all cases. When thread support is enabled we also need >them in various other places. However, this option also turns on the lock >prefix for the atomic operations, forcing them to always be atomic. I am >not sure that this has no unexpected side-effects on the code. > George. > > > On Jan 6, 2015, at 4:12 PM, George Bosilca wrote: > > > Successive alteration of the build system made this option less > relevant and especially less meaningful. However, while removing it > sounds like a desirable cleanup, we have to keep in mind that this will > enable all locks and all memory barriers even in cases where they are > not necessary (via OPAL_WANT_SMP_LOCKS). > > > > Thus, I do not share the enthusiasm of the others. I would prefer to > see an evaluation of the impact on performance, a patch and a little bit > more than 1/2 a day to react to it (the proposed deadline seems to be > today January 6th) before such a drastic change. > > > > George. > > > > > > On Tue, Jan 6, 2015 at 12:05 PM, Ralph Castain > wrote: > > +1 > > > > > On Jan 6, 2015, at 9:04 AM, Jeff Squyres (jsquyres) > wrote: > > > > > > +1 > > > > > > On Jan 6, 2015, at 11:55 AM, Howard Pritchard > wrote: > > > > > >> I agree. Please remove this config option. > > >> > > >> 2015-01-06 9:44 GMT-07:00 Nathan Hjelm : > > >> > > >> What: Remove the --disable-smp-locks configure option from master. > > >> > > >> Why: Use of this option produces incorrect results/undefined > behavior > > >> when any shared memory BTL is in use. Since BTL usage is enabled > even > > >> when using cm for point-to-point this option can never be safely > used. > > >> > > >> When: Thurs, Jan 6, 2015 > > >> > > >> -Nathan > > >> > > >> ___ > > >> 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/2015/01/16736.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/2015/01/16737.php > > > > > > > > > -- > > > Jeff Squyres > > > jsquy...@cisco.com > > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > > > > ___ > > > 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/2015/01/16739.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/2015/01/16740.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/2015/01/16741.php > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > ___ > 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/2015/01/16742.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/2015/01/
Re: [OMPI devel] pthreads (was: Re: RFC: remove --disable-smp-locks)
Ok. Then I'm good with Gilles' plan. Anyone else? On Jan 7, 2015, at 11:29 AM, Nathan Hjelm wrote: > > Yes, we decided some time back that pthreads is a minimum requirement > for Open MPI. > > -Nathan > > On Wed, Jan 07, 2015 at 04:26:01PM +, Jeff Squyres (jsquyres) wrote: >> On Jan 7, 2015, at 11:22 AM, Gilles Gouaillardet >> wrote: >> >>> Valid options are : >>> --with-threads e.g. --with-threads=posix e.g. default >>> And >>> --with-threads=no >>> >>> Except configure will explicitly fail if --with-threads=no is used >> >> Which is the moral equivalent of not having this option. :-) (which I >> think is your point :-) ) >> >>> So bottom line, pthreads and pthreads only are usable >> >> But my question remains: we all decided that OMPI will *require* pthreads, >> right? (i.e., configure will fail if pthreads are not available) >> >> I am being pedantic here, I know -- but it's slightly different than what >> you're saying, and this threading stuff is already quite confusing... >> >> >>> Cheers, >>> >>> Gilles >>> >>> "Jeff Squyres (jsquyres)" さんのメール: On Jan 7, 2015, at 4:25 AM, Gilles Gouaillardet wrote: > Talking about thread support ... > > i made a RFC several monthes ago in order to remove the > --with-threads option from configure > > /* ompi requires pthreads, no more, no less */ Did we decide this? (that OMPI *requires* pthreads) I *think* we did. But I just want to make sure that my (terrible) memory is correct... > it was accepted, but i could not find the time to implement it ... > > basically, i can see three steps : > > 1) remove the --with-threads option from configure, check for pthreads, > and set the > OPAL_HAVE_POSIX_THREADS macro to 1 Sounds good. > 2) step 1) + remove #ifdef OPAL_HAVE_POSIX_THREADS and remove dead code > (e.g. #ifndef OPAL_HAVE_POSIX_THREADS) Also make configure fail if pthreads are not available. > 3) step 1) + step 2) + remove the OPAL thread abstraction layer > > is it a good idea to implement steps 2) and 3) ? > i mean, if there is a chance we might support an other threading model in > the future, > it might be better to keep some dead code for the time being. I think the consensus was that pthreads are fine for the foreseeable future. If we need to re-add the threading abstraction layer, it's annoying, but not difficult. Might as well simplify what we have, since there's no other threading system on the horizon that we need to worry about. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ ___ 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/2015/01/16750.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/2015/01/16751.php >> >> >> -- >> Jeff Squyres >> jsquy...@cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> ___ >> 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/2015/01/16752.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/2015/01/16753.php -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] pthreads (was: Re: RFC: remove --disable-smp-locks)
Yes, we decided some time back that pthreads is a minimum requirement for Open MPI. -Nathan On Wed, Jan 07, 2015 at 04:26:01PM +, Jeff Squyres (jsquyres) wrote: > On Jan 7, 2015, at 11:22 AM, Gilles Gouaillardet > wrote: > > > Valid options are : > > --with-threads e.g. --with-threads=posix e.g. default > > And > > --with-threads=no > > > > Except configure will explicitly fail if --with-threads=no is used > > Which is the moral equivalent of not having this option. :-) (which I think > is your point :-) ) > > > So bottom line, pthreads and pthreads only are usable > > But my question remains: we all decided that OMPI will *require* pthreads, > right? (i.e., configure will fail if pthreads are not available) > > I am being pedantic here, I know -- but it's slightly different than what > you're saying, and this threading stuff is already quite confusing... > > > > Cheers, > > > > Gilles > > > > "Jeff Squyres (jsquyres)" さんのメール: > >> On Jan 7, 2015, at 4:25 AM, Gilles Gouaillardet > >> wrote: > >> > >>> Talking about thread support ... > >>> > >>> i made a RFC several monthes ago in order to remove the > >>> --with-threads option from configure > >>> > >>> /* ompi requires pthreads, no more, no less */ > >> > >> Did we decide this? (that OMPI *requires* pthreads) > >> > >> I *think* we did. But I just want to make sure that my (terrible) memory > >> is correct... > >> > >>> it was accepted, but i could not find the time to implement it ... > >>> > >>> basically, i can see three steps : > >>> > >>> 1) remove the --with-threads option from configure, check for pthreads, > >>> and set the > >>> OPAL_HAVE_POSIX_THREADS macro to 1 > >> > >> Sounds good. > >> > >>> 2) step 1) + remove #ifdef OPAL_HAVE_POSIX_THREADS and remove dead code > >>> (e.g. #ifndef OPAL_HAVE_POSIX_THREADS) > >> > >> Also make configure fail if pthreads are not available. > >> > >>> 3) step 1) + step 2) + remove the OPAL thread abstraction layer > >>> > >>> is it a good idea to implement steps 2) and 3) ? > >>> i mean, if there is a chance we might support an other threading model in > >>> the future, > >>> it might be better to keep some dead code for the time being. > >> > >> I think the consensus was that pthreads are fine for the foreseeable > >> future. If we need to re-add the threading abstraction layer, it's > >> annoying, but not difficult. Might as well simplify what we have, since > >> there's no other threading system on the horizon that we need to worry > >> about. > >> > >> -- > >> Jeff Squyres > >> jsquy...@cisco.com > >> For corporate legal information go to: > >> http://www.cisco.com/web/about/doing_business/legal/cri/ > >> > >> ___ > >> 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/2015/01/16750.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/2015/01/16751.php > > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > ___ > 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/2015/01/16752.php pgp6ohjPwejs2.pgp Description: PGP signature
Re: [OMPI devel] pthreads (was: Re: RFC: remove --disable-smp-locks)
On Jan 7, 2015, at 11:22 AM, Gilles Gouaillardet wrote: > Valid options are : > --with-threads e.g. --with-threads=posix e.g. default > And > --with-threads=no > > Except configure will explicitly fail if --with-threads=no is used Which is the moral equivalent of not having this option. :-) (which I think is your point :-) ) > So bottom line, pthreads and pthreads only are usable But my question remains: we all decided that OMPI will *require* pthreads, right? (i.e., configure will fail if pthreads are not available) I am being pedantic here, I know -- but it's slightly different than what you're saying, and this threading stuff is already quite confusing... > Cheers, > > Gilles > > "Jeff Squyres (jsquyres)" さんのメール: >> On Jan 7, 2015, at 4:25 AM, Gilles Gouaillardet >> wrote: >> >>> Talking about thread support ... >>> >>> i made a RFC several monthes ago in order to remove the >>> --with-threads option from configure >>> >>> /* ompi requires pthreads, no more, no less */ >> >> Did we decide this? (that OMPI *requires* pthreads) >> >> I *think* we did. But I just want to make sure that my (terrible) memory is >> correct... >> >>> it was accepted, but i could not find the time to implement it ... >>> >>> basically, i can see three steps : >>> >>> 1) remove the --with-threads option from configure, check for pthreads, and >>> set the >>> OPAL_HAVE_POSIX_THREADS macro to 1 >> >> Sounds good. >> >>> 2) step 1) + remove #ifdef OPAL_HAVE_POSIX_THREADS and remove dead code >>> (e.g. #ifndef OPAL_HAVE_POSIX_THREADS) >> >> Also make configure fail if pthreads are not available. >> >>> 3) step 1) + step 2) + remove the OPAL thread abstraction layer >>> >>> is it a good idea to implement steps 2) and 3) ? >>> i mean, if there is a chance we might support an other threading model in >>> the future, >>> it might be better to keep some dead code for the time being. >> >> I think the consensus was that pthreads are fine for the foreseeable future. >> If we need to re-add the threading abstraction layer, it's annoying, but >> not difficult. Might as well simplify what we have, since there's no other >> threading system on the horizon that we need to worry about. >> >> -- >> Jeff Squyres >> jsquy...@cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> ___ >> 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/2015/01/16750.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/2015/01/16751.php -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] pthreads (was: Re: RFC: remove --disable-smp-locks)
Valid options are : --with-threads e.g. --with-threads=posix e.g. default And --with-threads=no Except configure will explicitly fail if --with-threads=no is used So bottom line, pthreads and pthreads only are usable Cheers, Gilles "Jeff Squyres (jsquyres)" さんのメール: >On Jan 7, 2015, at 4:25 AM, Gilles Gouaillardet > wrote: > >> Talking about thread support ... >> >> i made a RFC several monthes ago in order to remove the >> --with-threads option from configure >> >> /* ompi requires pthreads, no more, no less */ > >Did we decide this? (that OMPI *requires* pthreads) > >I *think* we did. But I just want to make sure that my (terrible) memory is >correct... > >> it was accepted, but i could not find the time to implement it ... >> >> basically, i can see three steps : >> >> 1) remove the --with-threads option from configure, check for pthreads, and >> set the >> OPAL_HAVE_POSIX_THREADS macro to 1 > >Sounds good. > >> 2) step 1) + remove #ifdef OPAL_HAVE_POSIX_THREADS and remove dead code >> (e.g. #ifndef OPAL_HAVE_POSIX_THREADS) > >Also make configure fail if pthreads are not available. > >> 3) step 1) + step 2) + remove the OPAL thread abstraction layer >> >> is it a good idea to implement steps 2) and 3) ? >> i mean, if there is a chance we might support an other threading model in >> the future, >> it might be better to keep some dead code for the time being. > >I think the consensus was that pthreads are fine for the foreseeable future. >If we need to re-add the threading abstraction layer, it's annoying, but not >difficult. Might as well simplify what we have, since there's no other >threading system on the horizon that we need to worry about. > >-- >Jeff Squyres >jsquy...@cisco.com >For corporate legal information go to: >http://www.cisco.com/web/about/doing_business/legal/cri/ > >___ >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/2015/01/16750.php
[OMPI devel] pthreads (was: Re: RFC: remove --disable-smp-locks)
On Jan 7, 2015, at 4:25 AM, Gilles Gouaillardet wrote: > Talking about thread support ... > > i made a RFC several monthes ago in order to remove the > --with-threads option from configure > > /* ompi requires pthreads, no more, no less */ Did we decide this? (that OMPI *requires* pthreads) I *think* we did. But I just want to make sure that my (terrible) memory is correct... > it was accepted, but i could not find the time to implement it ... > > basically, i can see three steps : > > 1) remove the --with-threads option from configure, check for pthreads, and > set the > OPAL_HAVE_POSIX_THREADS macro to 1 Sounds good. > 2) step 1) + remove #ifdef OPAL_HAVE_POSIX_THREADS and remove dead code > (e.g. #ifndef OPAL_HAVE_POSIX_THREADS) Also make configure fail if pthreads are not available. > 3) step 1) + step 2) + remove the OPAL thread abstraction layer > > is it a good idea to implement steps 2) and 3) ? > i mean, if there is a chance we might support an other threading model in the > future, > it might be better to keep some dead code for the time being. I think the consensus was that pthreads are fine for the foreseeable future. If we need to re-add the threading abstraction layer, it's annoying, but not difficult. Might as well simplify what we have, since there's no other threading system on the horizon that we need to worry about. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] RFC: remove --disable-smp-locks
On Jan 6, 2015, at 6:16 PM, George Bosilca wrote: > This is correct. We need the memory fences and atomic operations for shared > memory in all cases. When thread support is enabled we also need them in > various other places. However, this option also turns on the lock prefix for > the atomic operations, forcing them to always be atomic. I am not sure that > this has no unexpected side-effects on the code. Mmm. Is this right? Right now, the default is --enable-smp-locks. This enables the sm/vader BTLs to be correct. It also turns on some other required atomic magic which is necessary for correctness. If you use --disable-smp-locks, the sm/vader BTLs will be incorrect. Atomics won't necessarily be atomic, so they might/will be incorrect in multi-threaded scenarios. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] ompi-master build error : make can require autotools
On Jan 6, 2015, at 9:52 PM, Ralph Castain wrote: > The 1.12 series had a set of problems caused by a changeover in the > maintainers, so it should never be used. I’m not sure if any of those issues > are behind this problem, but it could be so. > > Anyway, I think pretty much all of us are using automake 1.14 by this time. > We can discuss how far up to move the requirement, but I think 1.14 would be > the right place. Fair enough. I don't think we should change the set used to generate 1.8 series tarballs, though. I think it's a good policy to keep the same autotools tuple for the entire series, unless there's a good reason to change. As Dave noted, our default on our Cisco dev cluster is AM 1.13.3. Probably just because that was the most recent version when we last did maintenance on our AM toolchain. It's easy enough for us to update, though. Another point would probably be to update http://www.open-mpi.org/source/building.php to say that the versions listed for master are a minimum version -- devs can use whatever they want (that works :-) ). The other table lines list what tuple is used to create those tarballs. Also note that per https://github.com/open-mpi/ompi/issues/311, we cannot upgrade past LT 2.4.2 right now. This looks like a bug in LT itself (not OMPI), but I don't have a workaround/solution to go beyond LT 2.4.2 right now (and I think it's not high priority... yet). In conclusion: I'll bump the AM version for master on building.php to be 1.13.3 because I know for a fact that it works. If we want to move it higher than that, I don't have too strong an opinion. :-) I think all the other versions for master are fine. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] RFC: remove --disable-smp-locks
Talking about thread support ... i made a RFC several monthes ago in order to remove the --with-threads option from configure /* ompi requires pthreads, no more, no less */ it was accepted, but i could not find the time to implement it ... basically, i can see three steps : 1) remove the --with-threads option from configure, check for pthreads, and set the OPAL_HAVE_POSIX_THREADS macro to 1 2) step 1) + remove #ifdef OPAL_HAVE_POSIX_THREADS and remove dead code (e.g. #ifndef OPAL_HAVE_POSIX_THREADS) 3) step 1) + step 2) + remove the OPAL thread abstraction layer is it a good idea to implement steps 2) and 3) ? i mean, if there is a chance we might support an other threading model in the future, it might be better to keep some dead code for the time being. any thoughts ? Cheers, Gilles On 2015/01/07 8:16, George Bosilca wrote: > On Tue, Jan 6, 2015 at 4:25 PM, Jeff Squyres (jsquyres) > wrote: > >> My enthusiasm for this was primarily because I thought we had talked about >> exactly this issue before (at the last meeting in Chicago?), and decided >> that the option is useless -- in part, because it always *must* be enabled >> for shared memory correctness. >> >> Is that incorrect? >> > This is correct. We need the memory fences and atomic operations for shared > memory in all cases. When thread support is enabled we also need them in > various other places. However, this option also turns on the lock prefix > for the atomic operations, forcing them to always be atomic. I am not sure > that this has no unexpected side-effects on the code. > > George. > > > >> >> On Jan 6, 2015, at 4:12 PM, George Bosilca wrote: >> >>> Successive alteration of the build system made this option less relevant >> and especially less meaningful. However, while removing it sounds like a >> desirable cleanup, we have to keep in mind that this will enable all locks >> and all memory barriers even in cases where they are not necessary (via >> OPAL_WANT_SMP_LOCKS). >>> Thus, I do not share the enthusiasm of the others. I would prefer to see >> an evaluation of the impact on performance, a patch and a little bit more >> than 1/2 a day to react to it (the proposed deadline seems to be today >> January 6th) before such a drastic change. >>> George. >>> >>> >>> On Tue, Jan 6, 2015 at 12:05 PM, Ralph Castain wrote: >>> +1 >>> On Jan 6, 2015, at 9:04 AM, Jeff Squyres (jsquyres) < >> jsquy...@cisco.com> wrote: +1 On Jan 6, 2015, at 11:55 AM, Howard Pritchard >> wrote: > I agree. Please remove this config option. > > 2015-01-06 9:44 GMT-07:00 Nathan Hjelm : > > What: Remove the --disable-smp-locks configure option from master. > > Why: Use of this option produces incorrect results/undefined behavior > when any shared memory BTL is in use. Since BTL usage is enabled even > when using cm for point-to-point this option can never be safely used. > > When: Thurs, Jan 6, 2015 > > -Nathan > > ___ > 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/2015/01/16736.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/2015/01/16737.php -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ ___ 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/2015/01/16739.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/2015/01/16740.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/2015/01/16741.php >> >> >> -- >> Jeff Squyres >> jsquy...@cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> ___ >> 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/2015/01/16742.php >> > > > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.o
