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
> On Jul 12, 2016, at 12:01 AM, Sreenidhi Bharathkar Ramesh
> wrote:
>
> [ 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 ?
It was completely discontinued. The problem with the opti
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-
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
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 becau
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
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 --wit
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
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?
On Jan 6, 2015, at 4
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_W
+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
+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
>
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
13 matches
Mail list logo
