[ query regarding an old thread ] Hi,
It looks like "--disable-smp-locks" is still available as an option. 1. Will this be continued or deprecated ? 2. Under what circumstances would "--disable-smp-locks" be useful ? In our experiments on ARM64 platform, it was seen that OSU Micro collective benchmarks actually degraded when "--disable-smp-locks" was used. Hence, asking. Please let me know. Thanks, - Sreenidhi. ----- ----- ----- ----- Subject: Re: [OMPI devel] RFC: remove --disable-smp-locks From: Jeff Squyres (jsquyres) (jsquyres_at_[hidden]) List-Post: devel@lists.open-mpi.org Date: 2015-01-07 14:14:30 Added to the wiki / agenda. On Jan 7, 2015, at 11:35 AM, Nathan Hjelm <hjelmn_at_[hidden]> 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) >> <jsquyres_at_[hidden]> 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 <bosilca_at_[hidden]> 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 <rhc_at_[hidden]> >> wrote: >>> +1 >>> >>>> On Jan 6, 2015, at 9:04 AM, Jeff Squyres (jsquyres) >> <jsquyres_at_[hidden]> wrote: >>>> >>>> +1 >>>> >>>> On Jan 6, 2015, at 11:55 AM, Howard Pritchard <hppritcha_at_[hidden]> >> wrote: >>>> >>>>> I agree. Please remove this config option. >>>>> >>>>> 2015-01-06 9:44 GMT-07:00 Nathan Hjelm <hjelmn_at_[hidden]>: >>>>> >>>>> 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
