> We intend to provide support for a default MPI_COMM_SELF implementation of
> shared memory windows in ch3. Shared memory windows are fully implemented
> in Nemesis, but not ch3, so if you were to try using them right now with
> sock, you would get a not implemented error. If anyone needs this
> (presumably for portability), I'd be happy to bump the priority on ticket
> #1666.
How is this not a no-op implementation for MPI_COMM_SELF? All you
need to support is load-store on local memory, no?
Jeff
--
Jeff Hammond
Argonne Leadership Computing Facility
University of Chicago Computation Institute
jhammond(a)alcf.anl.gov / (630) 252-5381
http://www.linkedin.com/in/jeffhammondhttps://wiki.alcf.anl.gov/parts/index.php/User:Jhammond
On 1/23/13 2:50 PM, Pavan Balaji wrote:
>
> On 01/23/2013 02:44 PM US Central Time, Dave Goodell wrote:
>>> Are you still supporting ch3:sock?
>>
>> We are, although we have chosen not to support a small subset of the
>> MPI-3 functionality in ch3:sock, such as shared memory windows.
>
> It's a pedantic detail, but MPI-3 says that shared memory is supported
> on a communicator returned by Comm_split_type. For ch3:sock, we return
> MPI_COMM_SELF, so technically we do support shared memory windows, but
> only on that process :-D.
We intend to provide support for a default MPI_COMM_SELF implementation
of shared memory windows in ch3. Shared memory windows are fully
implemented in Nemesis, but not ch3, so if you were to try using them
right now with sock, you would get a not implemented error. If anyone
needs this (presumably for portability), I'd be happy to bump the
priority on ticket #1666.
https://trac.mpich.org/projects/mpich/ticket/1666
~Jim.
On Wed, Jan 23, 2013 at 2:44 PM, Dave Goodell <goodell(a)mcs.anl.gov> wrote:
>> Is there some test we can do to check whether ch3:sock is being used so that we can choose a safe algorithm?
>
> A run-time test that doesn't require looking at which symbols are compiled into the app? I can't think of one off the top of my head, although I suppose we could add one in the future via either MPI_T or the new MPI_Get_library_version routine.
I think that MPI_Get_library_version is the most sensible way to do
it. There's some precedent for this to return a lot of information:
http://blogs.cisco.com/performance/mpi-3-small-new-function-mpi_get_library….
Jeff
--
Jeff Hammond
Argonne Leadership Computing Facility
University of Chicago Computation Institute
jhammond(a)alcf.anl.gov / (630) 252-5381
http://www.linkedin.com/in/jeffhammondhttps://wiki.alcf.anl.gov/parts/index.php/User:Jhammond
On 01/23/2013 02:44 PM US Central Time, Dave Goodell wrote:
>> Are you still supporting ch3:sock?
>
> We are, although we have chosen not to support a small subset of the
> MPI-3 functionality in ch3:sock, such as shared memory windows.
It's a pedantic detail, but MPI-3 says that shared memory is supported
on a communicator returned by Comm_split_type. For ch3:sock, we return
MPI_COMM_SELF, so technically we do support shared memory windows, but
only on that process :-D.
-- Pavan
--
Pavan Balaji
http://www.mcs.anl.gov/~balaji
On Jan 23, 2013, at 2:13 PM CST, Jed Brown wrote:
> As we've discussed here several times before, PETSc's --download-mpich option uses ch3:sock by default because this issue
>
> http://trac.mpich.org/projects/mpich/ticket/79
>
> makes nemesis unusable when oversubscribed.
Your complaint has been duly noted (again).
> We're also checking for MPI_Ibarrier and using Torsten's "nonblocking consensus" algorithm when possible. Unfortunately, MPI_Ibarrier deadlocks when run over ch3:sock. (Both procs have posted the Ibarrier, but the requests never complete.) I can prepare a reduced test case if you'd like.
Hmm… it looks like we aren't poking NBC progress properly when a "test" or "iprobe" routine is called. MPIDI_CH3i_Progress_test is missing a call to MPIDU_Sched_progress: http://git.mpich.org/mpich.git/blob/refs/heads/master:/src/mpid/ch3/channel…
I'm surprised this isn't caught by the "coll/nonblock3" test, although we may just be making too much progress some other way, or we may not have enough coverage of the test itself in that test: http://git.mpich.org/mpich.git/blob/refs/heads/master:/test/mpi/coll/nonblo…
A modest test case would be very helpful.
> Are you still supporting ch3:sock?
We are, although we have chosen not to support a small subset of the MPI-3 functionality in ch3:sock, such as shared memory windows. We still run sock in the nightly tests:
http://www.mpich.org/static/cron/tests/#hydra-ch3:sock
> Is there some test we can do to check whether ch3:sock is being used so that we can choose a safe algorithm?
A run-time test that doesn't require looking at which symbols are compiled into the app? I can't think of one off the top of my head, although I suppose we could add one in the future via either MPI_T or the new MPI_Get_library_version routine.
-Dave
As we've discussed here several times before, PETSc's --download-mpich
option uses ch3:sock by default because this issue
http://trac.mpich.org/projects/mpich/ticket/79
makes nemesis unusable when oversubscribed. We're also checking for
MPI_Ibarrier and using Torsten's "nonblocking consensus" algorithm when
possible. Unfortunately, MPI_Ibarrier deadlocks when run over ch3:sock.
(Both procs have posted the Ibarrier, but the requests never complete.) I
can prepare a reduced test case if you'd like. Are you still supporting
ch3:sock?
Is there some test we can do to check whether ch3:sock is being used so
that we can choose a safe algorithm?
Pavan,
That's what I needed. Thanks!
Jody
-----Original Message-----
From: Pavan Balaji [mailto:[email protected]]
Sent: Wednesday, January 23, 2013 2:04 PM
To: discuss(a)mpich.org
Cc: Jody Steadman
Subject: Re: [mpich-discuss] MPICH_PORT_RANGE
Hi Judy,
We haven't tracked the number of ports that we need to create, but it'll be around 3-4 persistent ports + all the per-process ephemeral ports for inter-process connections that are setup on-demand.
-- Pavan
On 01/23/2013 10:07 AM US Central Time, Jody Steadman wrote:
> Hi All,
>
> What is the minimum number of ports required by MPICH for a single run?
> I'm in a situation where I need to limit the amount of ports in an
> environment, but could not find any documentation that says for each
> run MPICH needs x number of ports available in the range.
>
> I'm using MPICH version 1.4.1p1 with Hydra.
>
> Thanks,
>
> Jody
>
> _______________________________________________
> discuss mailing list discuss(a)mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss
--
Pavan Balaji
http://www.mcs.anl.gov/~balaji
Hi Judy,
We haven't tracked the number of ports that we need to create, but it'll
be around 3-4 persistent ports + all the per-process ephemeral ports for
inter-process connections that are setup on-demand.
-- Pavan
On 01/23/2013 10:07 AM US Central Time, Jody Steadman wrote:
> Hi All,
>
> What is the minimum number of ports required by MPICH for a single run?
> I�m in a situation where I need to limit the amount of ports in an
> environment, but could not find any documentation that says for each run
> MPICH needs x number of ports available in the range.
>
> I�m using MPICH version 1.4.1p1 with Hydra.
>
> Thanks,
>
> Jody
>
> _______________________________________________
> discuss mailing list discuss(a)mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss
--
Pavan Balaji
http://www.mcs.anl.gov/~balaji
On Jan 23, 2013, at 12:22 PM CST, Evren Yurtesen IB wrote:
> It appears there are problems with mpich2 packages provided by ubuntu 12.04/12.10 etc. I think the problem is the compile time arguments they use when building them.
>
> I made a bug report to ubuntu launchpad but they suggested I should contact you also. Can somebody please have a look and comment on the bug report?
>
> https://bugs.launchpad.net/ubuntu/+source/mpich2/+bug/1045326
Pavan Balaji, who commented 2012-09-03, represents "us" on this matter.
To me the problem just looks like a fundamental disagreement/incompatibility between BLCR and Valgrind (at least for certain versions of each package). See this BLCR thread: https://hpcrdm.lbl.gov/pipermail/checkpoint/2011-September/000311.html
Based on what Paul said in that link and some cursory googling, it sounds like that issue was never upstreamed to the Valgrind folks.
I agree with you that the easiest way to resolve the Launchpad bug is to just omit the checkpointing arguments, although this has the downside of disabling this functionality. A more involved fix would be to patch the BLCR library in the fashion mentioned in the lbl.gov link above.
> PS. I used to have an account 'yurtesen' in the bug reporting system, but it does not seem to function anymore, was it removed somehow? who can see that?
We were getting too much spam from self-registered trac accounts, so we deleted all of the non-ANL accounts in the system. We (those with trac admin access) now have to create trac accounts by hand. I have restored your account on trac.mpich.org. You probably have received an email about this already. I will email you your initial password off-list so that you can login and reset it.
-Dave
It appears there are problems with mpich2 packages provided by ubuntu
12.04/12.10 etc. I think the problem is the compile time arguments they use
when building them.
I made a bug report to ubuntu launchpad but they suggested I should contact you
also. Can somebody please have a look and comment on the bug report?
https://bugs.launchpad.net/ubuntu/+source/mpich2/+bug/1045326
Thanks,
Evren
PS. I used to have an account 'yurtesen' in the bug reporting system, but it
does not seem to function anymore, was it removed somehow? who can see that?
