On 14 Jun 2010, at 17:27, Martin Schulz wrote:
> Hi all,
>
> Attached is the latest and updated version of the MPIR document, which John
> DelSignore put together. The intent is still to publish this through the MPI forum
> as an official document. The details for this are still tbd. and Jeff will lead a
> discussion on this topic during the forum this week.
I think this is a good document and a huge step forward, I've learnt a few things I hadn't realised about the interface before.
Largely I'm in agreement with the document but I disagree with some parts of and would like clarification on a few aspects of MPIR_PROCDESC.
Section 9.2
Like the original work this document specifies a definition for MPIR_PROCDESC, it however then goes on to say that the definition isn't fixed but rather is up to the implementation.
typedef struct {
char *host_name;
char *executable_name;
int pid;
} MPIR_PROCDESC;
Section 9.2 paragraph 4:
The pid member is the integer process identifier of the MPI process. Note that historically pid was defined as a C language int, which is an integer of an unknown size, which might be smaller than the size of a process identifier for the target system. Implementations should define pid as an integer size that is large enough to hold a process identifier for the target system. For example, implementations should use pid_t as the type of pid provided that pid_t is an integer type.
Are there MPI librarys in existence which don't use int as the type for pid? I've certainly not seen any and never seen it necessary to read the type of MPIR_PROCDESC because it's type is well specified. Actually MPICH2 tried changing this recently from a int to a long and I made them change it back.
Following on from this I don't believe that section 4.1 applies, or at least not as strictly as it's written currently. It's possible to extract the information from the starter process without the debug information being present.
Ashley.
--
Ashley Pittman, Bath, UK.
Padb - A parallel job inspection tool for cluster computing
http://padb.pittman.org.uk
On 17 Jun 2010, at 03:58, Martin Schulz wrote:
> Hi Greg,
>
> I (and I think most WG members) agree with you on most, if not all of the
> points. Nobody is happy with the interface as it is and would like to see
> something much better (incl. John from Totalview). However, this is how
> things are since they have been organically grown.
Indeed, I think chapter 1 of the document describes this quite well.
I have some more specific feedback about a few aspects of the document that I hope to send along later today or tomorrow.
Ashley.
--
Ashley Pittman, Bath, UK.
Padb - A parallel job inspection tool for cluster computing
http://padb.pittman.org.uk
Hi Jeff,
Thanks for leading this discussion at the meeting this week.
All this sounds like a solid plan - if we don't get any further
major comments anymore (I have a few feedback requests
outstanding), I'll work with John on the conversion. That
should not be that hard.
Martin
On Jun 15, 2010, at 3:30 PM, Jeff Squyres wrote:
> Results from today...
>
> The Forum was in favor of "blessing" the MPIR document as a separate
> document (i.e., outside of MPI-3) and hosting it on www.*mpi-
> forum.org. They felt that it would be important to follow the same
> voting procedure as is followed for the official MPI document. That
> means The reason for this is that this will become an important
> document, for the following reasons:
>
> - A "gold standard" for tool writers
> - A "gold standard" for MPI implementors
> - A document to be used for procurements (i.e., RFPs say that MPI
> implementations/tools support what is described in this document,
> etc.)
>
> Hence, my $0.02 on what we should do is the following (reference:
> list of upcoming MPI Forum meetings: http://*meetings.mpi-forum.org/
> Meeting_details.php):
>
> - convert the current document to the MPI Forum Latex format
> - send the resulting document to the MPI Forum mailing list a
> minimum of 2 weeks before the September/Stuttgart meeting (this is a
> requirement for an official reading)
> - bring up this latex-ified document in September/Stuttgart for an
> official first reading
> - bring up this document in October/Chicago for a 1st vote
> - bring up this document in December/California for a 2nd vote
>
> I believe that it is also worthwhile for our fearless leader
> (Martin) to send a mail to the general MPI Forum list to announce
> our intention to execute this plan, and that it has the support of
> the attendees of the June MPI Forum (for the benefit of those who
> are not here at the meeting).
>
> --
> Jeff Squyres
> jsquyres(a)cisco.com
> For corporate legal information go to:
> http://*www.*cisco.com/web/about/doing_business/legal/cri/
>
>
> _______________________________________________
> Mpi3-tools mailing list
> Mpi3-tools(a)lists.mpi-forum.org
> http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
>
________________________________________________________________________
Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA
Hi Greg,
I (and I think most WG members) agree with you on most, if not all of
the
points. Nobody is happy with the interface as it is and would like to
see
something much better (incl. John from Totalview). However, this is how
things are since they have been organically grown.
In this first step we just wanted to document how the current
interface works,
so that tools that want to code to MPIR or MPI libraries and resource
managers
that want to offer MPIR can do so in a unified way. This will be the
first
reliable document to this effect and that is what Jeff meant with gold
standard.
This is not supposed to be a definition of the latest and greatest for
MPI-3
and hence we also decided to not push for the inclusion into the
standard.
Instead this will only be a side document, but blessed by the forum. I
(and
if I can speak for the rest of the WG members, we) think that this is
essential
in the short term to give tools something to work with and to act as a
starting point for any future interface and improvement.
In the mid/long term (hopefully within MPI-3) we would like to establish
something better than the current MPIR and some of your ideas came up in
the discussions, others make perfectly sense to me and I would like to
see them included. I know that John has some concrete ideas on this
and that there is interest from David at Allinea. Also, both the MPICH
and
the OpenMPI groups have thought about these issues.
Putting these ideas together into a new API draft would be great.
However,
I don't see myself being able to drive another API besides the MPIT API
we are currently working on. If you have the interest and the time to
get
together with the folks and help drive this activity, that would be
great.
The MPI tools WG would certainly be the right forum for this and if it
makes
sense to schedule a or even regular meetings for this, we can certainly
do that. Let me know.
Thanks,
Martin
On Jun 15, 2010, at 5:45 PM, Greg Watson wrote:
> I'll reiterate again my comments/suggestions regarding the tool
> daemon launch extension.
>
> 1. A number of debuggers and tools use the MPI runtime to launch
> their server processes rather than having to implement a second
> parallel launch mechanism. In lieu of standard infrastructure for
> launching tools, it makes sense to use the MPI runtime if possible.
> This approach is currently supported by Open MPI, MPICH2, PE and
> probably others as well.
>
> 2. The current extension relies on reading/writing memory in the
> starter process. This is adequate (although complicated) for
> debuggers, but does not work with other sorts of tools. In order to
> address this, I would like to see these features available from the
> command line as well, and would suggest a requirement that the tool
> daemon variables be able to be specified on the command line of the
> starter process.
>
> 3. The extension provides no control of where or how many server
> processes are launched. I presume the intention is one server
> process per MPI process, but this is not specified, and is probably
> not desirable on shared memory and other types of architectures. At
> a minimum, a "one server process per node" variable is desirable,
> such as "MPIR_one_server_per_node" or something similar. However, it
> may be desirable to make this completely general by allowing the use
> of the same process allocation mechanism provided by the MPI
> implementation.
>
> 4. The extension does not provide any mechanism for server processes
> to identify themselves or the MPI process(es) they are interested
> in. I would suggest a requirement that the each server command line
> or environment be supplied with (a) the MPI rank(s) of the MPI
> process(es) associated with each server; and (b) the PID's of the
> MPI process(es) if launched by the MPI runtime.
>
> 5. Some tools would prefer to start the MPI processes rather than
> attach to existing processes (which implies a ptrace requirement). I
> would suggest the optional variable "MPIR_external_spawn" be
> specified that indicates to the MPI runtime that the processes will
> be spawned externally. For this mode of launch, the identification
> information provided in (3) would be used by the MPI implementation
> to complete the MPI initialization, as well as the by tool. This
> variable would be available only on MPI implementations that support
> this startup mechanism.
>
> As mentioned, a number of MPI implementations already provide most
> of these features, so the burden of adding this support should not
> be great. Providing a standard mechanism for tool daemon launch
> would go a long way to addressing some of the tool infrastructure
> problems that affect most systems today.
>
> The current tool daemon launch extension is clearly targeted at
> TotalView and not designed to be flexible enough for other tools and
> debuggers. If the document goes ahead as-is, it can hardly be said
> to be a "gold standard" for tool writers.
>
> Regards,
> Greg
>
>
> On Jun 14, 2010, at 12:27 PM, Martin Schulz wrote:
>
>> Hi all,
>>
>> Attached is the latest and updated version of the MPIR document,
>> which John
>> DelSignore put together. The intent is still to publish this
>> through the MPI forum
>> as an official document. The details for this are still tbd. and
>> Jeff will lead a
>> discussion on this topic during the forum this week.
>>
>> We don't have a tools WG meeting scheduled for meeting, but if you
>> have
>> any comments or feedback (on the document or how we should publish
>> it),
>> please post it to the list. If necessary or useful, we can also
>> dedicate one
>> of the upcoming tools TelCons for this.
>>
>> Thanks!
>>
>> Martin
>>
>> PS: Feel free to distribute the document further, in particular to
>> tool and
>> MPI developers.
>>
>>
>> <MPIR Process Acquisition Interface 2010-06-11.pdf>
>>
>> ________________________________________________________________________
>> Martin Schulz, schulzm(a)llnl.gov, http://*people.llnl.gov/schulzm
>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>>
>>
>>
>> _______________________________________________
>> Mpi3-tools mailing list
>> Mpi3-tools(a)lists.mpi-forum.org
>> http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
>
> _______________________________________________
> Mpi3-tools mailing list
> Mpi3-tools(a)lists.mpi-forum.org
> http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
________________________________________________________________________
Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA
I'll reiterate again my comments/suggestions regarding the tool daemon launch extension.
1. A number of debuggers and tools use the MPI runtime to launch their server processes rather than having to implement a second parallel launch mechanism. In lieu of standard infrastructure for launching tools, it makes sense to use the MPI runtime if possible. This approach is currently supported by Open MPI, MPICH2, PE and probably others as well.
2. The current extension relies on reading/writing memory in the starter process. This is adequate (although complicated) for debuggers, but does not work with other sorts of tools. In order to address this, I would like to see these features available from the command line as well, and would suggest a requirement that the tool daemon variables be able to be specified on the command line of the starter process.
3. The extension provides no control of where or how many server processes are launched. I presume the intention is one server process per MPI process, but this is not specified, and is probably not desirable on shared memory and other types of architectures. At a minimum, a "one server process per node" variable is desirable, such as "MPIR_one_server_per_node" or something similar. However, it may be desirable to make this completely general by allowing the use of the same process allocation mechanism provided by the MPI implementation.
4. The extension does not provide any mechanism for server processes to identify themselves or the MPI process(es) they are interested in. I would suggest a requirement that the each server command line or environment be supplied with (a) the MPI rank(s) of the MPI process(es) associated with each server; and (b) the PID's of the MPI process(es) if launched by the MPI runtime.
5. Some tools would prefer to start the MPI processes rather than attach to existing processes (which implies a ptrace requirement). I would suggest the optional variable "MPIR_external_spawn" be specified that indicates to the MPI runtime that the processes will be spawned externally. For this mode of launch, the identification information provided in (3) would be used by the MPI implementation to complete the MPI initialization, as well as the by tool. This variable would be available only on MPI implementations that support this startup mechanism.
As mentioned, a number of MPI implementations already provide most of these features, so the burden of adding this support should not be great. Providing a standard mechanism for tool daemon launch would go a long way to addressing some of the tool infrastructure problems that affect most systems today.
The current tool daemon launch extension is clearly targeted at TotalView and not designed to be flexible enough for other tools and debuggers. If the document goes ahead as-is, it can hardly be said to be a "gold standard" for tool writers.
Regards,
Greg
On Jun 14, 2010, at 12:27 PM, Martin Schulz wrote:
> Hi all,
>
> Attached is the latest and updated version of the MPIR document, which John
> DelSignore put together. The intent is still to publish this through the MPI forum
> as an official document. The details for this are still tbd. and Jeff will lead a
> discussion on this topic during the forum this week.
>
> We don't have a tools WG meeting scheduled for meeting, but if you have
> any comments or feedback (on the document or how we should publish it),
> please post it to the list. If necessary or useful, we can also dedicate one
> of the upcoming tools TelCons for this.
>
> Thanks!
>
> Martin
>
> PS: Feel free to distribute the document further, in particular to tool and
> MPI developers.
>
>
> <MPIR Process Acquisition Interface 2010-06-11.pdf>
>
> ________________________________________________________________________
> Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm
> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>
>
>
> _______________________________________________
> Mpi3-tools mailing list
> Mpi3-tools(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
Results from today...
The Forum was in favor of "blessing" the MPIR document as a separate document (i.e., outside of MPI-3) and hosting it on www.mpi-forum.org. They felt that it would be important to follow the same voting procedure as is followed for the official MPI document. That means The reason for this is that this will become an important document, for the following reasons:
- A "gold standard" for tool writers
- A "gold standard" for MPI implementors
- A document to be used for procurements (i.e., RFPs say that MPI implementations/tools support what is described in this document, etc.)
Hence, my $0.02 on what we should do is the following (reference: list of upcoming MPI Forum meetings: http://meetings.mpi-forum.org/Meeting_details.php)
- convert the current document to the MPI Forum Latex format
- send the resulting document to the MPI Forum mailing list a minimum of 2 weeks before the September/Stuttgart meeting (this is a requirement for an official reading)
- bring up this latex-ified document in September/Stuttgart for an official first reading
- bring up this document in October/Chicago for a 1st vote
- bring up this document in December/California for a 2nd vote
I believe that it is also worthwhile for our fearless leader (Martin) to send a mail to the general MPI Forum list to announce our intention to execute this plan, and that it has the support of the attendees of the June MPI Forum (for the benefit of those who are not here at the meeting).
--
Jeff Squyres
jsquyres(a)cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Hi all,
Attached is the latest and updated version of the MPIR document, which
John
DelSignore put together. The intent is still to publish this through
the MPI forum
as an official document. The details for this are still tbd. and Jeff
will lead a
discussion on this topic during the forum this week.
We don't have a tools WG meeting scheduled for meeting, but if you have
any comments or feedback (on the document or how we should publish it),
please post it to the list. If necessary or useful, we can also
dedicate one
of the upcoming tools TelCons for this.
Thanks!
Martin
PS: Feel free to distribute the document further, in particular to
tool and
MPI developers.
________________________________________________________________________
Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA
