FWIW: I’m not planning on releasing tomorrow as we aren’t ready. We aren’t
releasing with a bug as bad as threading on by default as we know we can’t
really support that situation.
Nothing sacred about the release date - it’s just a target.
Frankly, I would even listen to the argument of flat-o
On Nov 6, 2014, at 3:39 PM, Joshua Ladd wrote:
> Thank you for taking the time to investigate this, Jeff. SC is a hectic and
> stressful time for everyone on this list with many deadlines looming. This
> bug isn't a priority for us, however, it seems to me that your original
> revert, the one
Thank you for taking the time to investigate this, Jeff. SC is a hectic and
stressful time for everyone on this list with many deadlines looming. This
bug isn't a priority for us, however, it seems to me that your original
revert, the one that simply wants to disable threading by default (and for
g
This thread digressed significantly from the original bug report; I did not
realize that the discussion was revolving around the fact that
MPI_THREAD_MULTIPLE no longer works *at all*.
So here's where we are:
1. MPI_THREAD_MULTIPLE doesn't work, even if you --enable-mpi-thread-multiple
2. It s
Jeff wrote:
MPI_THREAD_MULTIPLE support barely works in v1.8. Why have it on by
default, especially when there's a performance penalty?
I think the "barely works" state of threading support is a stronger
argument for return to the 1.6.x behavior than PSM performance. Who knows
what subtle bugs h
On Nov 5, 2014, at 12:03 PM, Joshua Ladd wrote:
> I think this is a pretty significant change in behavior for a minor release,
> Jeff. According to the interested parties:
>
> "I'm reporting a performance (message rate 16%, latency 3%) regression when
> using PSM that occurred between OMPI v1.
I don’t think anyone is proposing a major change in behavior. We are proposing
to fix a bug that crept into the 1.8 series without prior detection - i.e.,
that mpi-thread-multiple was enabled by default, which is definitely not the
intention. I just looked at the configure code, and it does beha
I think this is a pretty significant change in behavior for a minor
release, Jeff. According to the interested parties:
"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,
I think the issue is that the revert may have resulted in having to set both
—enable-mpi-thread-multiple and —enable-opal-multi-threads, and Mike is asking
that the first automatically turn on the second
> On Nov 5, 2014, at 8:51 AM, Jeff Squyres (jsquyres)
> wrote:
>
> On Nov 5, 2014, at 11:
On Nov 5, 2014, at 11:43 AM, Mike Dubman wrote:
> sorry,
> >>>"now we use only this "--enable-mpi-thread-multiple" and it worked."
>
> I meant it worked fine before the "configure logic" changes.
It went back to the way it was in in the v1.6 series.
The issue is that --enable-mpi-thread-multi
sorry,
>>>"now we use only this "--enable-mpi-thread-multiple" and it worked."
I meant it worked fine before the "configure logic" changes.
On Wed, Nov 5, 2014 at 6:39 PM, Jeff Squyres (jsquyres)
wrote:
> I thought you said passing only --enable-mpi-thread-multiple made it
> work...?
>
> On Nov
I thought you said passing only --enable-mpi-thread-multiple made it work...?
On Nov 5, 2014, at 11:37 AM, Mike Dubman wrote:
> the problem is that now the behavior is changed.
> Before: user provided single flag and could use MT support.
> Now same method will not work starting from v1.8.4 whic
the problem is that now the behavior is changed.
Before: user provided single flag and could use MT support.
Now same method will not work starting from v1.8.4 which is production
branch and will live for a long time with it.
Is that possible that some1 familiar with this configure kung-fu will fi
On Nov 5, 2014, at 9:42 AM, Mike Dubman wrote:
> Hey Jeff,
>
> now we use only this "--enable-mpi-thread-multiple" and it worked.
> does it mean that now we need to pass "--enable-mpi-thread-multiple
> --enable-opal-multi-threads" to get it working again?
> Maybe if one of the params used it sh
Hey Jeff,
now we use only this "--enable-mpi-thread-multiple" and it worked.
does it mean that now we need to pass "--enable-mpi-thread-multiple
--enable-opal-multi-threads"
to get it working again?
Maybe if one of the params used it should enable another one as well?
Thanks
On Wed, Nov 5, 2014
$ ./configure --help |& grep thread
code will ever run in SMP or multi-threaded
--enable-opal-multi-threads
Enable thread support inside OPAL (default:
--enable-mpi-thread-multiple
Enable MPI_THREAD_MULTIPLE support (
Jeff,
What configure voodoo do we need to add to our MTT to get this functional
again?
Josh
On Tue, Nov 4, 2014 at 12:33 PM, Ralph Castain
wrote:
> That would be correct - we restored some configure flags that are required
> to make multi-thread programs work. Jeff can probably provide more in
That would be correct - we restored some configure flags that are required to
make multi-thread programs work. Jeff can probably provide more info.
> On Nov 4, 2014, at 9:15 AM, Alina Sklarevich
> wrote:
>
> Hi,
>
> We observe a hang when running the multi-threading support test "latency.c"
18 matches
Mail list logo
