Re: [MTT devel] [MTT svn] svn:mtt-svn r964

[Ethan Mallove]

Pak, we're scratching our heads on this new "developer
results into central database" use case. Could you give more
details?

-Ethan


On Thu, Aug/30/2007 01:32:26PM, Jeff Squyres wrote:
> Ethan --
> 
> Did Pak really mean to submit to the database?
> 
> On Aug 30, 2007, at 1:22 PM, jjhur...@osl.iu.edu wrote:
> 
> > Author: jjhursey
> > Date: 2007-08-30 13:22:06 EDT (Thu, 30 Aug 2007)
> > New Revision: 964
> > URL: https://svn.open-mpi.org/trac/mtt/changeset/964
> >
> > Log:
> > Increase the 'mpi_version' char length due to the following error:
> >
> > SQL QUERY: INSERT INTO mpi_get
> > (mpi_get_id, mpi_name, mpi_version) VALUES
> > ('507', 'developer',
> > '_workspace_paklui_ompi-paklui-1.2-pml_shared- 
> > install_SunOS_sparc_2007.08.29_bin_mpirun')
> > SQL ERROR: ERROR:  value too long for type character varying(32)
> > SQL ERROR:
> >
> >
> >
> > Text files modified:
> >trunk/server/sql/v3/schemas-v3.sql | 2 +-
> >1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > Modified: trunk/server/sql/v3/schemas-v3.sql
> > == 
> > 
> > --- trunk/server/sql/v3/schemas-v3.sql  (original)
> > +++ trunk/server/sql/v3/schemas-v3.sql  2007-08-30 13:22:06 EDT  
> > (Thu, 30 Aug 2007)
> > @@ -107,7 +107,7 @@
> >  -- Current Max: 21 chars
> >  mpi_namevarchar(64) NOT NULL DEFAULT 'bogus',
> >  -- Current Max: 24 chars
> > -mpi_version varchar(32) NOT NULL DEFAULT 'bogus',
> > +mpi_version varchar(128) NOT NULL DEFAULT 'bogus',
> >
> >  UNIQUE (
> >  mpi_name,
> > ___
> > mtt-svn mailing list
> > mtt-...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-svn
> 
> 
> -- 
> Jeff Squyres
> Cisco Systems
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] No nightly summary last night?

[Ethan Mallove]

cron/alerts.php said this last night:

  Sorry, this page is not mirrored.  Please see the http://www.open-mpi.org/;>original version of this
  page on the main Open MPI web site.

Is "curl" confused by deny_mirror()'s new location (see
r949)?

-Ethan


On Thu, Aug/30/2007 04:34:34PM, Josh Hursey wrote:
> Humm. I think Ethan has this in his crontab and should be able to  
> check if it is giving errors.
> 
> I'm not currently subscribed to the nightly emails, I probably should  
> do that again.
> 
> -- Josh
> 
> On Aug 30, 2007, at 3:30 PM, Jeff Squyres wrote:
> 
> > Come to think of it, I didn't get mails this morning, either.
> >
> > And -- arrgh -- we'll have to fix the index.php <--> reporter.php,
> > thing, too.  But that change was made after 9am this morning, so it
> > should not have affected last night's / this morning's e-mails.
> >
> >
> > On Aug 30, 2007, at 3:26 PM, Jeff Squyres wrote:
> >
> >> I don't have nightly summary mails from last night -- did anyone else
> >> get them?
> >>
> >> -- 
> >> Jeff Squyres
> >> Cisco Systems
> >>
> >> ___
> >> mtt-devel mailing list
> >> mtt-de...@open-mpi.org
> >> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
> >
> >
> > -- 
> > Jeff Squyres
> > Cisco Systems
> >
> > ___
> > mtt-devel mailing list
> > mtt-de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] First cut at MTT web pages

[Ethan Mallove]

On Thu, Sep/06/2007 08:35:01AM, Jeff Squyres wrote:
> I put up a skeleton of the MTT web pages on the OMPI web site, but  
> didn't link to them from anywhere.  This actually involved changing a  
> bunch of infrastructure because we published the name /projects/mtt/  
> in the paper but PLPA was under /software/plpa/.  So I had to move  
> PLPA to be under /projects/plpa/etc.  You probably don't care  
> about the details.  ;-)
> 
> Anyway, /projects/mtt/ now exists and has skeleton content.  I even  
> put up dummy tarballs (that are empty).  Two things to note:
> 
> 1. There are 3 places where I have links to MTT content on the OMPI  
> web site.  If you are in a personal checkout (i.e., if the first two  
> chars of REQUEST_URI are "/~"), the links will show up and be noted  
> with "(FIX)" in red.  If you're on the live OMPI web site, the links  
> don't show up (yet).
> 
> 2. Our OMPI MTT testing results are in /mtt/ -- the MTT project site  
> is /projects/mtt/.  This actually creates a problem for the left-hand  
> navigation scheme because it looks at the basename of the subdir to  
> know when to print the sub-menus.  For example, if you view a  
> personal checkout and go to /projects/mtt/, you'll see the MTT  
> project sub-menu listed twice on the left.  I could add a hackaround  
> in the PHP of the OMPI web site, but thinking about it a little, I  
> wonder if it would be better to simply move the OMPI MTT testing  
> results to /testing/ (with an appropriate apache-level redirects left  
> at /mtt/ so that all old permalinks and whatnot continue to work).   

PHP issues aside, I think having these two is confusing:

  http://www.open-mpi.org/mtt
  http://www.open-mpi.org/projects/mtt

Nothing in the first link indicates test results (that was
something I liked about "reporter.php" :-)) So yes, I favor 
renaming mtt/index.php.


> We'll need to get everyone to update their client INI files, though  
> -- I'm not sure that LWP will understand a POST redirect...?

Can't we move mtt/index.php to mtt/results/index.php or
mtt/testing/index.php (I prefer "results"), and leave
mtt/submit/index.php alone?

-Ethan


> 
> Comments?
> 
> -- 
> Jeff Squyres
> Cisco Systems
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] sanity check a reporter commit

[Ethan Mallove]

I don't see the problem from the permalink posted in the
ticket. Pak and I have also been looking at performance
results this week without running into the jpgraph error.

-Ethan


On Thu, Sep/13/2007 04:44:20PM, Jeff Squyres wrote:
> Ethan --
> 
> Can you sanity check a commit I just made in the reporter?
> 
>  https://svn.open-mpi.org/trac/mtt/changeset/1014
> 
> It's to address this bug:
> 
>  https://svn.open-mpi.org/trac/mtt/ticket/307
> 
> I tried a variety of different graphs and scales and my change seems  
> to be working, but I'd appreciate a sanity check.  Thanks...
> 
> -- 
> Jeff Squyres
> Cisco Systems
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] MTT server error (user: sun)

[Ethan Mallove]

On Mon, Sep/17/2007 10:46:45AM, Josh Hursey wrote:
> I've been getting quite a few errors from submit.php of
> the below  form. It seems that the MPI Install that is
> being referenced is not  valid. Could this is an 'already
> installed' issue where the user is  trying to submit
> results to the database without having submitted an
> mpi_install?


You are correct. Some test reporter-less runs were done
before some runs that used the MTTDatabase reporter were
done. I guess the rule of thumb is to, from the outset, run
using --trial if you plan to eventually send to the
database.

-Ethan

> 
> -- Josh
> 
> On Sep 17, 2007, at 10:37 AM, jjhur...@open-mpi.org wrote:
> 
> > find_mpi_install_id():
> > The following SELECT returned -1:
> > ---
> > SELECT mpi_install_id
> > FROM mpi_install NATURAL JOIN
> >  mpi_get NATURAL JOIN
> >  compilerNATURAL JOIN
> >  compute_cluster NATURAL JOIN
> >  submit
> > WHERE
> > mpi_version = '1.2.4b1r16122M'  AND
> > mpi_name= 'developer'  AND
> > compiler_version= '4.1.2'  AND
> > hostname= 'fog01'  AND
> > mtt_client_version= '2.1devel'  AND
> > local_username= 'paklui'  AND
> > platform_name= 'fog01'
> > ORDER BY mpi_install_id DESC limit 1
> > ---
> >
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

[MTT devel] Handling "Interrupted system call" with MTT

[Ethan Mallove]

On certain NFS servers, I run into the error message
"Interrupted system call" when executing long running
commands such as "make all". One solution I've been able to
use is to setup an NFS mount point solely for the cluster
I'm using, but this is not always an option. The below link
advises to restart the build on "Interrupted system call":

  http://developers.sun.com/solaris/articles/parallel_make.html

I wrapped the GNU_Install.pm make commands in a do-while to
effect the build restarts. E.g.,

  do {
  $x = MTT::DoCommand::Cmd("make install")
  } while (!MTT::DoCommand::wsuccess($x->{exit_status}) and 
($x->{result_stderr} =~ /interrupted system call/i));

As long as make emits "interrupted system call" and fails,
MTT will keep restarting make.

I realize this is ugly, but is it acceptable?

-Ethan

Re: [MTT devel] Handling "Interrupted system call" with MTT

[Ethan Mallove]

On Wed, Oct/17/2007 07:45:53AM, Jeff Squyres wrote:
> On Oct 16, 2007, at 6:36 PM, Ethan Mallove wrote:
> 
> >>> The bail is that "make" will eventually succeed or fail
> >>> with something other than "interrupted system call". Do
> >>> we need another condition?
> >>
> >> I'm just worried that Sun's NFS will somehow get in a
> >> perpetual "interrupted system call" loop such that you'll
> >> never actually break out of it.
> >
> > How about a counter? E.g., after "x" number of "interrupted
> > system call" messages, MTT moves on. Or should the "command
> > restart" go in DoCommand.pm so we can have a timeout?
>
> Either or both of those would be fine (don't we have a timeout in  
> DoCommand.pm already?).

There is a timeout in DoCommand, but currently I keep
reinvoking DoCommand on each "interrupted system call" so
the timeout gets reset each time. This would not be the case
if the do-while were to go in DoCommand. Then again, an
infinite loop is certain in the case of a command that is
*expected* to output "interrupted system call".

-Ethan

> 
> > I also noticed that our build script (which prints hundreds
> > of "interrupted system call" messages per build, but does
> > not seem to die because of them) uses "make -j 24" while MTT
> > has been using "make -j 4". I'll experiment with -j.
> 
> I know that Terry/Sun and co. spent a good amount of time trying to  
> solve the "interrupted system call" error -- they may have some more  
> information for you, such as how/why it happens...?
> 
> -- 
> Jeff Squyres
> Cisco Systems
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] [MTT svn] svn:mtt-svn r1094 (for review)

[Ethan Mallove]

Josh,

Before this gets committed to the live submit.php, can you
look at this? It should only effect the "environment" field.

Thanks,
Ethan


On Thu, Nov/01/2007 03:30:26PM, emall...@osl.iu.edu wrote:
> Author: emallove
> Date: 2007-11-01 15:30:26 EDT (Thu, 01 Nov 2007)
> New Revision: 1094
> URL: https://svn.open-mpi.org/trac/mtt/changeset/1094
> 
> Log:
>  * "environment" field was not getting inserted due to
>a faulty `isset()` check
>  * Added a second MTT DB admin
> 
> 
> Text files modified: 
>trunk/server/php/submit/index.php |28 +++- 
>
>1 files changed, 19 insertions(+), 9 deletions(-)
> 
> Modified: trunk/server/php/submit/index.php
> ==
> --- trunk/server/php/submit/index.php (original)
> +++ trunk/server/php/submit/index.php 2007-11-01 15:30:26 EDT (Thu, 01 Nov 
> 2007)
> @@ -235,6 +235,9 @@
>  
>  for($i = 0; $i < $n; $i++) {
>  
> +# The POST fields are enumerated starting at 1
> +$j = $i + 1;
> +
>  
>  # Select/Insert: performance
>  # Currently only support latency/bandwidth
> @@ -363,7 +366,7 @@
>  #
>  # Select/Insert: Environment
>  $results_idxs_hash['environment_id'] = 0;
> -if( isset($_POST['environment']) ) {
> +if( isset($_POST["environment_$j"]) ) {
>  $stmt_fields = array("environment");
>  
>  $stmt_values = array(get_scalar($param_set['environment'], $i) );
> @@ -567,6 +570,9 @@
>  }
>  
>  for($i = 0; $i < $n; $i++) {
> +
> +# The POST fields are enumerated starting at 1
> +$j = $i + 1;
>  
>  
>  # Select/Insert: test_build_compiler -> compiler
> @@ -629,7 +635,8 @@
>  #
>  # Select/Insert: Environment
>  $results_idxs_hash['environment_id'] = 0;
> -if( isset($_POST['environment']) ) {
> +
> +if( isset($_POST["environment_$j"]) ) {
>  $stmt_fields = array("environment");
>  
>  $stmt_values = array(get_scalar($param_set['environment'], $i) );
> @@ -1084,6 +1091,9 @@
>  
>  for($i = 0; $i < $n; $i++) {
>  
> +# The POST fields are enumerated starting at 1
> +$j = $i + 1;
> +
>  
>  # Select/Insert: compute_cluster
>  $stmt_fields = array("platform_name",
> @@ -1185,7 +1195,7 @@
>  #
>  # Select/Insert: Environment
>  $results_idxs_hash['environment_id'] = 0;
> -if( isset($_POST['environment']) ) {
> +if( isset($_POST["environment_$j"]) ) {
>  $stmt_fields = array("environment");
>  
>  $stmt_values = array(get_scalar($param_set['environment'], $i) );
> @@ -1767,8 +1777,8 @@
>  
>  $php_auth_user = $_SERVER['PHP_AUTH_USER'];
>  $user  = $_POST['email'];
> -#JJH$admin = 'ethan.mall...@sun.com';
> -$admin = 'jjhur...@open-mpi.org';
> +$admin1= 'jjhur...@open-mpi.org';
> +$admin2= 'ethan.mall...@sun.com';
>  $date  = date('r');
>  $phpversion= phpversion();
>  $boundary  = md5(time());
> @@ -1778,8 +1788,8 @@
>  $attachment = chunk_split(base64_encode(file_get_contents($filename)));
>  
>  $headers = << -From: $admin
> -Reply-To: $admin
> +From: $admin1
> +Reply-To: $admin1
>  Date: $date
>  X-Mailer: PHP v$phpversion
>  MIME-Version: 1.0
> @@ -1808,8 +1818,8 @@
>  if (preg_match("/\w+@\w+/", $user, $m))
>  mail($user, "MTT server error", $message, $headers);
>  
> -# Email the MTT database administrator
> -mail($admin, "MTT server error (user: $php_auth_user)", $message, 
> $headers);
> +# Email the MTT database administrator(s)
> +mail("$admin1, $admin2", "MTT server error (user: $php_auth_user)", 
> $message, $headers);
>  
>  # Whack the temp file
>  unlink($filename);
> ___
> mtt-svn mailing list
> mtt-...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-svn

Re: [MTT devel] Database Notice

[Ethan Mallove]

"pg_dump -s" seems to show that we are set until 2009?

(Just put a note in my calendar about this for late December 2008 :-))

On Wed, Jan/09/2008 04:07:01PM, Josh Hursey wrote:
> I was showing MTT to someone today and noticed that it was performing  a
> bit slower than it should. After taking a look under the hood I
> discovered that we were missing  the 2008 partition tables. :(
> 
> I'll keep you posted on this. Let me know if you have any problems in  
> the mean time.
> 
> -- Josh
> 
> Short Version:
> --
> We did not lose any data. The accumulated data was just put in a non- 
> optimal table, thus making queries slow. I added the 2008 partition  
> tables, and things should be back to normal. All new data will be  
> added correctly to the partition tables per usual.
> 
> There will be a lingering slowdown if anyone queries for results from  
> Jan 1, 2008 00:00 to ~Jan 9, 2008 15:15. I'm trying to fix this at the  
> moment (see Long Version).
> 
> Long Version:
> -
> I totally forgot to upload the new tables to the database. Sorry guys :(
> 
> All the data accumulated from the first of the year was put in the  
> main table for mpi_install/test_build/test_run instead of in their  
> respective date partitioned tables. This means that when someone  
> searches for something in the date range Jan 1, 2008 00:00 to ~Jan 9,  
> 2008 15:15 the database is going to do a bit of thrashing since the  
> optimizer is going to try to look to the partition table first then  
> failing that it will look at *all* the tables including the root  
> table. Luckily the optimizer seems to start with the root table so it  
> is not as bad as it could be, but still slower than it should be. :/
> 
> Currently this effects:
>   mpi_install:   434 tuples
>   test_build : 2,174 tuples
>   test_run   : 1,077,117 tuples
> 
> I think I can fix this but I want to experiment a bit before  
> manipulating real data. I think I can create a transaction that does  
> something like:
> Start Transaction
> Drop check constraints on test_run
> Save effected tuples to disk
> Drop effected tuples from test_run
> Add back effected tuples to test_run (inserting into partition tables)
> Add back check constraints
> .. do the same for test_build, and mpi_install
> End Transaction

So you need to copy the data out of the root table into *_y2008_m01_wk1?
Something like the below does not work because it might collide with
someone trying to INSERT into this week's partition table?

  SELECT * FROM mpi_install INTO mpi_install_y2008_m01_wk1;

Could another option would be to turn off submit.php for 
a few minutes and do the above SELECT INTO?

-Ethan


> 
> 
> Note for Josh: start_timestamp >= DATE '2008-01-01' and  
> start_timestamp < TIMESTAMP '2008-01-09 03:11'
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] MTT Visualization

[Ethan Mallove]

Woo hoo!

The reporter has been much much more useful since the DB
optimizations, though I wonder if in the next batch of
changes we could also have #296 (a few more columns are
needed)? (Not really related to visibility, but I thought
I'd speak my mind while there seems to be another round of
database stuff going on :-))

Stats visualization would be interesting on virtually any
column. Particularly combinations of these:

  * runtime_parameters
  * configure_options (broken down by individual options)
  * bitness
  * threadedness
  * np
  * platform
  * hardware

How much focus will be on the interface for generating
whatever visualization versus creating more static pictures?
It would be nice to have a flexible dashboard of some kind
that would allow us to generate ad hoc visualizations on any
combination of database columns.

-Ethan


On Thu, Jan/10/2008 10:29:32AM, Josh Hursey wrote:
> I met with Joseph Cottam (Grad student in my lab at IU)
> yesterday  about MTT visualization. He is working on some
> new visualization  techniques and wants to apply them to
> the MTT dataset.
> 
> Since we are ramping up to a v1.3 release we want to
> visualization to  support this effort. So we want to make
> sure that the visualization  will meet the development
> community's needs. We should probably ask  the devel-core
> list, but I thought I would start some of the  discussion
> here to make sure I am asking the right questions of the
> group.
> 
> To start I have some basic questions:
>   - How does Open MPI determine that it is stable enough to release?
>   - What dimensions of testing are most/least important (i.e.,  
> platforms, compilers, feature sets, scale, ...)?
>   - What other questions would be useful to answer with regard to  
> testing (thinking completely outside of the box)?
> * Example: Are we testing a specific platform/configuration set  
> too much/too little?
>   - Other questions you think we should pose to the group?
> 
> We are currently feeling out the domain of possibilities,
> but hope to  start doing some sketching some ideas in
> another week or so. This work  should proceed fairly
> quickly since we are targeting a paper about  this for the
> ACM Symposium on Software Visualization
> (http://www.softvis.org/ ) which is due in early April.
> How is that for expecting success :)
> 
> Cheers,
> Josh
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] MTT Visualization

[Ethan Mallove]

On Fri, Jan/11/2008 12:49:50PM, Jeff Squyres wrote:
> On Jan 10, 2008, at 10:29 AM, Josh Hursey wrote:
> 
> > I met with Joseph Cottam (Grad student in my lab at IU) yesterday
> > about MTT visualization. He is working on some new visualization
> > techniques and wants to apply them to the MTT dataset.
> 
> Awesome.
> 
> > Since we are ramping up to a v1.3 release we want to visualization to
> > support this effort. So we want to make sure that the visualization
> > will meet the development community's needs. We should probably ask
> > the devel-core list, but I thought I would start some of the
> > discussion here to make sure I am asking the right questions of the
> > group.
> 
> Sounds reasonable.
> 
> After a first go-round here, we might want to have a conversation with  
> the OMPI RM's to get their input - that would still be a small group  
> to get targeted feedback on these questions.
> 
> > To start I have some basic questions:
> >  - How does Open MPI determine that it is stable enough to release?
> 
> I personally have a Magic 8 Ball on my desk that I consult frequently  
> for questions like this.  ;-)
> 
> It's a mix of many different metrics, actually:
> 
> - stuff unrelated to MTT results:
> - how many trac tickets are open against that release and do we care
> - how urgent are the bug fixes that are included
> - external requirements (e.g., get an OMPI release out to meet the  
> OFED release schedule)
> - ...and probably others
> - related to MTT results
> - "good" coverage on platforms (where "platform" = host arch, OS,  
> OS version, compiler, compiler version, MCA params, interconnect, and  
> scheduler -- note that some of these are orthogonal from each other...)
> - the only failures and timeouts we have are a) repeatable, b)  
> consistent across multiple organizations (if relevant), and deemed to  
> be acceptable
> 
> >  - What dimensions of testing are most/least important (i.e.,
> > platforms, compilers, feature sets, scale, ...)?
> 
> This is a hard question.  :-\  I listed several dimensions above:
> 
> - host architecture
> - OS
> - OS version
> - compiler
> - compiler version
> - MCA parameters used
> - interconnect
> - scheduler
> 
> Here's some more:
> 
> - number of processes tested
> - layout of processes (by node, by proc, ...etc.)
> 
> I don't quite know how to order those in terms of priority.  :-\
> 
> >  - What other questions would be useful to answer with regard to
> > testing (thinking completely outside of the box)?
> >* Example: Are we testing a specific platform/configuration set
> > too much/too little?
> 
> This is a great question.
> 
> I would love to be able to configure this question -- e.g., are we  
> testing some MCA params too much/too little.
> 
> The performance stuff can always be visualized better, especially over  
> time. One idea is expressed in https://svn.open-mpi.org/trac/mtt/ticket/330 
> .
> 
> I also very much like the ideas in 
> https://svn.open-mpi.org/trac/mtt/ticket/236 
>   and https://svn.open-mpi.org/trac/mtt/ticket/302 (302 is not  
> expressed as a visualization issue, but it could be -- you can imagine  
> a tree-based display showing the relationships between phase results,  
> perhaps even incorporated with a timeline -- that would be awesome).
> 
> Here's a whacky idea -- can our MTT data be combined with SCM data  
> (SVN, in this case) to answer questions like:
> 
> - what parts of the code are the most troublesome?  i.e., when this  
> part of the code changes, these tests tend to break
> 
> - what tests seem to be related to what parts of the OMPI code base?
> 
> - who / what SVN commit(s) seemed to cause specific tests to break?
> 
> (this seems like a longer-term set of questions, but I thought I'd  
> bring it up...)


I like this idea :-) 

A level of redirection missing to do this is keying SVN r
numbers to files modified. We also need to be able to
somehow track *new* failures (see
https://svn.open-mpi.org/trac/mtt/ticket/70). E.g., "was it
*this* revision that broke test xyz or was it an older one?"

-Ethan


> 
> >  - Other questions you think we should pose to the group?
> >
> > We are currently feeling out the domain of possibilities, but hope to
> > start doing some sketching some ideas in another week or so. This work
> > should proceed fairly quickly since we are targeting a paper about
> > this for the ACM Symposium on Software Visualization 
> > (http://www.softvis.org/
> > ) which is due in early April. How is that for expecting success :)
> 
> Awesome.
> 
> -- 
> Jeff Squyres
> Cisco Systems
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

[MTT devel] Crazy SkaMPI graph rendering

[Ethan Mallove]

Jeff,

Do you have a link to a human-readable SkaMPI graph? I'm not
sure what to make of this:

  http://www.open-mpi.org/mtt/index.php?do_redir=515

I'm not sure what is lacking here, the client-side parsing
module, the server-side graph generation, or both.

-Ethan

Re: [MTT devel] Extracting transparent data from OMPI

[Ethan Mallove]

On Wed, Feb/06/2008 01:47:16PM, Jeff Squyres wrote:
> If this is going to be an OMPI-module-specific field, then
> running  ompi_info is fine.  But doesn't the GNU configure
> MTT module already  have the configure command line?


The scenario is that I'm using one plug-in to create Solaris
packages, but then I run tests against those packages using
an AlreadyInstalled MPI install. In other words, there is a
bit of a disconnect between the plug-in that accesses the
config.log and the plug-in that is actually used when
running the tests. It would be preferable to get the
configure options via ompi_info, if possible.

-Ethan


> 
> On Feb 6, 2008, at 1:44 PM, Josh Hursey wrote:
> 
> >
> > On Feb 6, 2008, at 11:32 AM, Ethan Mallove wrote:
> >
> >>>>
> >>>>
> >>>>> For the configure options we *could* parse the config.log to
> >>>>> extract
> >>>>> this data. The question is, if we did this, what do we want to
> >>>>> look?
> >>>>> And is this something we want to do? Is there another way?
> >>>>
> >>>> I think having a network-like field for the MPI install section
> >>>> might
> >>>> be good, and possibly have an OMPI:: funclet to automatically do  
> >>>> the
> >>>> parsing.  But we need to be mindful of MPIs that won't have a
> >>>> configure script, so what information goes there might be dubious
> >>>> (or
> >>>> just empty?).
> >>>
> >>> Yeah I think an Open MPI specific function should do the parsing
> >>> since
> >>> the configure options we want to grab will be specific to Open  
> >>> MPI. I
> >>> think in the case of no configure script it would just be empty.
> >>>
> >>
> >> The info we are looking for in config.log is not available
> >> in ompi_info? Parsing config.log throws a monkey wrench into
> >> an AlreadyInstalled testing scenario.
> >
> > I haven't looked to see for sure what the difference between the two
> > would be. But if ompi_info provides the information that we need, then
> > we can use it. Otherwise then we should try to parse config.log if it
> > is available.
> >
> > If we are doing an MPI Install and the build fails (due to maybe an
> > enabled feature) then we will have to depend upon parsing config.log
> > to see exactly which fields are available since ompi_info will not be
> > available to us at this point.
> >
> > -- Josh
> > ___
> > mtt-devel mailing list
> > mtt-de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
> 
> 
> -- 
> Jeff Squyres
> Cisco Systems
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] two recent commits

[Ethan Mallove]

On Wed, Feb/13/2008 10:35:51AM, Josh Hursey wrote:
> I just committed to the trunk two revisions that I want to push to the  
> Open MPI version of MTT:
>   https://svn.open-mpi.org/trac/mtt/changeset/1154
>   https://svn.open-mpi.org/trac/mtt/changeset/1155
> 
> r1154 is a performance fix which prevents us from executing the same  
> SQL query twice for every MTT Reporter request.

Whoa. Your fix does seem to be a 2x performance boost. Good one!

> 
> r1155 displays the total SQL execution time just after the Total  
> execution time at the bottom of the Reporter. I was noticing that over  
> a slow connection the difference between these two times was  
> significant.


Also very useful.

> I tested both of these and didn't see any problems, but wanted to ask  
> before I moved them to the Open MPI site version of MTT. A version of  
> the Reporter with these patches applied is available at the link below:
> http://osl.iu.edu/~jjhursey/research/mtt/server/php/index.php


I banged on this just now and it looks fine.

> 
> If I don't hear anything by the end of the day I'll push them in.


server/tools/commit-to-ompi-www.pl can be handy for
synchronizing mtt/server/php with ompi-www.

-Ethan

> 
> cheers,
> Josh
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] Weird MTT test names

[Ethan Mallove]

You can go ahead and delete those rows. (I believe they are
from the ORTE test suite I was working on.)

-Ethan

On Thu, Mar/06/2008 09:39:16AM, Josh Hursey wrote:
> I'm trying to cleanup the test_suite/test_name tables in the database,  
> removing some test names that are invalid and unreferenced.
> 
> In the process I found a whole series of test_names of the following  
> form:
> test_suite = trivial
> test_name  = MXIQNeaG8e-ping
> 
> For this particular one it points to Ethan:
> mtt=> select submit.* from submit natural join test_run where  
> test_name_id = 3947;
>   submit_id |hostname| local_username | http_username |  
> mtt_client_version
> ---+++--- 
> +
>2938 | burl-ct-v20z-2 | emallove   | sun   | 3.0a1
>2938 | burl-ct-v20z-2 | emallove   | sun   | 3.0a1
>2938 | burl-ct-v20z-2 | emallove   | sun   | 3.0a1
> (3 rows)
> 
> This particular data was submitted on Jan 1, 2008.
> 
> Any idea why we are seeing such cryptic names being submitted to the  
> database?
> 
> -- Josh
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] [MTT svn] svn:mtt-svn r1163

[Ethan Mallove]

On Mon, Mar/17/2008 11:01:11AM, Jeff Squyres wrote:
> Ethan --
> 
> Was there a case where the trivial plugin was not correctly detecting  
> what language bindings to compile against?
> 

The motivation is different than wanting to override the
language binding detection. Sometimes I *only* want to do
C++ tests (e.g., C++ STL sanity testing).

  [test-build-trivial]
  test_get = trivial
  save_stdout_on_success = 1
  merge_stdout_stderr = 1
  stderr_save_lines = 100
  module = Trivial

  [Test build: trivial]
  include_section = test-build-trivial

  # Only do C++ for STL section
  [Test build: trivial-stlport4]
  include_section = test-build-trivial
  trivial_tests_languages = c++
  trivial_tests_cflags = -library=stlport4

> (don't forget to add the new fields to the wiki)

Gotta copy *everything* in the CHANGES file to the wiki at some point!

-Ethan


> 
> 
> On Mar 17, 2008, at 10:55 AM, emall...@osl.iu.edu wrote:
> 
> > Author: emallove
> > Date: 2008-03-17 10:55:36 EDT (Mon, 17 Mar 2008)
> > New Revision: 1163
> > URL: https://svn.open-mpi.org/trac/mtt/changeset/1163
> >
> > Log:
> > * Added `trivial_tests_languages` to `Build/Trivial.pm`
> > * Added `clustertools_package_basedir` to
> >   `Install/ClusterTools.pm`
> > * Need to add whitespace to command in `Common/SCM.pm`
> >
> > Text files modified:
> >   trunk/CHANGES | 3 +++
> >   trunk/lib/MTT/Common/SCM.pm   |10 +-
> >   trunk/lib/MTT/MPI/Install/ClusterTools.pm | 9 ++---
> >   trunk/lib/MTT/Test/Build/Trivial.pm   |22 + 
> > +
> >   4 files changed, 32 insertions(+), 12 deletions(-)
> >
> > Modified: trunk/CHANGES
> > = 
> > = 
> > = 
> > = 
> > = 
> > = 
> > = 
> > = 
> > ==
> > --- trunk/CHANGES   (original)
> > +++ trunk/CHANGES   2008-03-17 10:55:36 EDT (Mon, 17 Mar 2008)
> > @@ -169,3 +169,6 @@
> >   - after_make_install
> >
> > - include_file(s) INI parameter - just like pre-processor "#include"  
> > directives
> > +
> > +- trivial_tests_languages - comma separated list of languages to  
> > use for trivial
> > +  tests (default: "c,c++,f77,f90").
> >
> > Modified: trunk/lib/MTT/Common/SCM.pm
> > = 
> > = 
> > = 
> > = 
> > = 
> > = 
> > = 
> > = 
> > ==
> > --- trunk/lib/MTT/Common/SCM.pm (original)
> > +++ trunk/lib/MTT/Common/SCM.pm 2008-03-17 10:55:36 EDT (Mon, 17 Mar  
> > 2008)
> > @@ -266,11 +266,11 @@
> >
> > # Append arguments to commands
> > # EAM: move to SVN.pm
> > -$command .= " $command_arguments "   if ($command_arguments);
> > -$command .= "-r $r "if ($r);
> > -$command .= "--username $username " if ($username);
> > -$command .= "--password $password " if ($password);
> > -$command .= "--no-auth-cache "  if ("0" eq $password_cache);
> > +$command .= " $command_arguments "  if ($command_arguments);
> > +$command .= " -r $r "if ($r);
> > +$command .= " --username $username " if ($username);
> > +$command .= " --password $password " if ($password);
> > +$command .= " --no-auth-cache "  if ("0" eq $password_cache);
> >
> > $subcommand .= " $subcommand_arguments "
> > if ($subcommand_arguments);
> >
> > Modified: trunk/lib/MTT/MPI/Install/ClusterTools.pm
> > = 
> > = 
> > = 
> > = 
> > = 
> > = 
> > = 
> > = 
> > ==
> > --- trunk/lib/MTT/MPI/Install/ClusterTools.pm   (original)
> > +++ trunk/lib/MTT/MPI/Install/ClusterTools.pm   2008-03-17 10:55:36  
> > EDT (Mon, 17 Mar 2008)
> > @@ -31,6 +31,7 @@
> > my $release_number;
> > my $product_version;
> > my $package_name_prefix;
> > +my $package_basedir;
> >
> > sub Install {
> > my ($ini, $section, $config) = @_;
> > @@ -74,6 +75,8 @@
> > $release_number = Value($ini, $section, "clustertools_release");
> > $product_version = Value($ini, $section,  
> > "clustertools_product_version");
> > $package_name_prefix = Value($ini, $section,  
> > "clustertools_package_name_prefix");
> > +$package_basedir = Value($ini, $section,  
> > "clustertools_package_basedir");
> > +$package_basedir = $package_basedir ? $package_basedir : "/opt";
> >
> > # Grab the internal repository revision number
> > my $internal_r_number = $config->{module_data}->{r};
> > @@ -218,11 +221,11 @@
> >
> > # Setup the Installer, if we pointed at one
> > my $installer_dir;
> > -my $installer_dir_src = basename($installer_hg_url);
> > if ($installer_hg_url) {
> >
> > MTT::Module::Run("MTT::Common::SCM::Mercurial", "Checkout",  
> > "hg clone $installer_hg_url", $installer_hg_url);
> >
> > +my $installer_dir_src = basename($installer_hg_url);
> > MTT::DoCommand::Pushdir($installer_dir_src);
> >
> > # Build the Install_Utilities 

Re: [MTT devel] [MTT svn] svn:mtt-svn r1164

[Ethan Mallove]

I sense this "do_not_run" stuff could be useful to me, but
I'm not sure. Can you give a simple use case for
"do_not_run"? Could "do_not_run" be achieved by just
commenting out the INI lines that pertain to a certain
group? E.g., do these "#" comments ...

  # simple_really_slow:tests = src/MPI_Isend_flood_c src/MPI_Send_flood_c
  # simple_really_slow:pass = (_wifexited(), (_wexitstatus(), 
0))
  # simple_really_slow:exclusive = 1
  # simple_really_slow:timeout = (90, (3, _np()))

... have the same effect as this?

  simple_really_slow:do_not_run = 1

-Ethan


On Thu, Mar/20/2008 10:03:50AM, jsquy...@osl.iu.edu wrote:
> Author: jsquyres
> Date: 2008-03-20 10:03:50 EDT (Thu, 20 Mar 2008)
> New Revision: 1164
> URL: https://svn.open-mpi.org/trac/mtt/changeset/1164
> 
> Log:
> Added parameter to Simple specify module: do_not_run.  If set to 1 for
> a specific subsection (and the subsection is exclusive), then those
> tests will not be run.  Handy for explicitly specifying tests that
> exist by should ''not'' be run.
> 
> Text files modified: 
>trunk/CHANGES|12 +---  
>   
>trunk/lib/MTT/Test/Specify/Simple.pm |14 ++
>   
>2 files changed, 23 insertions(+), 3 deletions(-)
> 
> Modified: trunk/CHANGES
> ==
> --- trunk/CHANGES (original)
> +++ trunk/CHANGES 2008-03-20 10:03:50 EDT (Thu, 20 Mar 2008)
> @@ -168,7 +168,13 @@
>- before_make_install
>- after_make_install
>  
> -- include_file(s) INI parameter - just like pre-processor "#include" 
> directives
> +- include_file(s) INI parameter - just like pre-processor "#include"
> +  directives
>  
> -- trivial_tests_languages - comma separated list of languages to use for 
> trivial 
> -  tests (default: "c,c++,f77,f90").
> +- trivial_tests_languages - comma separated list of languages to use
> +  for trivial tests (default: "c,c++,f77,f90").
> +
> +- added parameter to Simple specify module: do_not_run.  If set to 1
> +  for a specific subsection (and the subsection is exclusive), then
> +  those tests will not be run.  Handy for explicitly specifying tests
> +  that exist but should *not* be run.
> 
> Modified: trunk/lib/MTT/Test/Specify/Simple.pm
> ==
> --- trunk/lib/MTT/Test/Specify/Simple.pm  (original)
> +++ trunk/lib/MTT/Test/Specify/Simple.pm  2008-03-20 10:03:50 EDT (Thu, 
> 20 Mar 2008)
> @@ -62,6 +62,7 @@
>  # Now go through and see if any of the tests are marked as
>  # "exclusive". If they are, remove those tests from all other
>  # groups.
> +my @groups_to_delete;
>  foreach my $group (keys %$params) {
>  # If this group is marked as exclusive, remove each of its
>  # tests from all other groups
> @@ -85,6 +86,19 @@
>  }
>  }
>  }
> +
> +# After we've performed the exclusivity filter, if the tests
> +# are marked as "do_not_run", then delete this group (it's a
> +# way of specifying tests to *not* run).  Don't delete them
> +# now, it may (will?) screw up the outter loop's "foreach".
> +if ($params->{$group}->{do_not_run}) {
> +push(@groups_to_delete, $group);
> +}
> +}
> +
> +# Delete all the groups that were marked
> +foreach my $t (@groups_to_delete) {
> +delete $params->{$t};
>  }
>  
>  # Now go through those groups and make the final list of tests to pass
> ___
> mtt-svn mailing list
> mtt-...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-svn

Re: [MTT devel] [MTT svn] svn:mtt-svn r1176

[Ethan Mallove]

I like the "all" keyword. Are these no longer needed?

  _mpi_get_names()
  _mpi_install_names()
  _test_get_names()
  _test_build_names()

-Ethan

On Fri, Apr/04/2008 03:31:07PM, jsquy...@osl.iu.edu wrote:
> Author: jsquyres
> Date: 2008-04-04 15:31:07 EDT (Fri, 04 Apr 2008)
> New Revision: 1176
> URL: https://svn.open-mpi.org/trac/mtt/changeset/1176
> 
> Log:
> Allow "all" keyword in mpi_get, test_get, and test_build fields.
> 
> Text files modified: 
>trunk/CHANGES| 5 + 
>   
>trunk/lib/MTT/MPI/Install.pm | 9 ++--- 
>   
>trunk/lib/MTT/Test/Build.pm  | 9 ++--- 
>   
>trunk/lib/MTT/Test/Run.pm| 6 --
>   
>4 files changed, 21 insertions(+), 8 deletions(-)
> 
> Modified: trunk/CHANGES
> ==
> --- trunk/CHANGES (original)
> +++ trunk/CHANGES 2008-04-04 15:31:07 EDT (Fri, 04 Apr 2008)
> @@ -50,6 +50,11 @@
>  - _details() - pass arbitrary values from test run sections
> to the mpi details section, indexed by string
>  
> +- Allow mpi_get_name, test_get_name, and test_build_name fields to
> +  accept the special value "all", meaning that they'll use all
> +  corresponding sections that are found (vs. needing to list every
> +  section explicitly)
> +
>  - Added export for MTT_TEST_EXECUTABLE, may be used for clean up after
>mpi process : pkill -9 $MTT_TEST_EXECUTABLE
>  
> 
> Modified: trunk/lib/MTT/MPI/Install.pm
> ==
> --- trunk/lib/MTT/MPI/Install.pm  (original)
> +++ trunk/lib/MTT/MPI/Install.pm  2008-04-04 15:31:07 EDT (Fri, 04 Apr 
> 2008)
> @@ -199,7 +199,8 @@
>  
>  # This is only warning about the INI file; we'll see
>  # if we find meta data for the MPI get later
> -if (!$ini_full->SectionExists("mpi get: $mpi_get_name")) {
> +if ($mpi_get_name ne "all" &&
> +!$ini_full->SectionExists("mpi get: $mpi_get_name")) {
>  Warning("Warning: MPI Get section \"$mpi_get_name\" does 
> not seem to exist in the INI file\n");
>  }
>  
> @@ -207,7 +208,8 @@
>  # skip it.  Don't issue a warning because command line
>  # parameters may well have dictated to skip this MPI
>  # get section.
> -if (!exists($MTT::MPI::sources->{$mpi_get_name})) {
> +if ($mpi_get_name ne "all" && 
> +!exists($MTT::MPI::sources->{$mpi_get_name})) {
>  Debug("Have no sources for MPI Get \"$mpi_get_name\", 
> skipping\n");
>  next;
>  }
> @@ -217,7 +219,8 @@
>  
>  # For each MPI source
>  foreach my $mpi_get_key (keys(%{$MTT::MPI::sources})) {
> -if ($mpi_get_key eq $mpi_get_name) {
> +if ($mpi_get_name eq "all" ||
> +$mpi_get_key eq $mpi_get_name) {
>  
>  # For each version of that source
>  my $mpi_get = $MTT::MPI::sources->{$mpi_get_key};
> 
> Modified: trunk/lib/MTT/Test/Build.pm
> ==
> --- trunk/lib/MTT/Test/Build.pm   (original)
> +++ trunk/lib/MTT/Test/Build.pm   2008-04-04 15:31:07 EDT (Fri, 04 Apr 
> 2008)
> @@ -120,7 +120,8 @@
>  
>  # This is only warning about the INI file; we'll see
>  # if we find meta data for the test get later
> -if (!$ini_full->SectionExists("test get: $test_get_name")) {
> +if ($test_get_name ne "all" &&
> +!$ini_full->SectionExists("test get: $test_get_name")) {
>  Warning("Test Get section \"$test_get_name\" does not 
> seem to exist in the INI file\n");
>  }
>  
> @@ -128,14 +129,16 @@
>  # skip it.  Don't issue a warning because command line
>  # parameters may well have dictated to skip this
>  # section.
> -if (!exists($MTT::Test::sources->{$test_get_name})) {
> +if ($test_get_name ne "all" &&
> +!exists($MTT::Test::sources->{$test_get_name})) {
>  Debug("Have no sources for Test Get \"$test_get_name\", 
> skipping\n");
>  next;
>  }
>  
>  # Find the matching test source
>  foreach my $test_get_key (keys(%{$MTT::Test::sources})) {
> -if ($test_get_key eq $test_get_name) {
> +if ($test_get_name eq "all" ||
> +$test_get_key eq $test_get_name) {
>  

Re: [MTT devel] [MTT bugs] [MTT] #355: tooltips for reporter

[Ethan Mallove]

Do these work for you?

  http://tinyurl.com/49m2n4

They work for me in IE (Windows) and Mozilla (Solaris), but
not in Firefox and Opera. The joys of JavaScript :-)

-Ethan


On Mon, Apr/21/2008 01:32:49PM, MTT wrote:
> #355: tooltips for reporter
> -+--
>  Reporter:  jsquyres |   Owner:   
>  Type:  enhancement  |  Status:  new  
>  Priority:  major|   Milestone:  v3.1 
> Component:  Server side  | Version:  trunk
>  Keywords:   |  
> -+--
>  Currently, when browsing the reporter, if you hover over a link in the
>  reporter, the browser (or mail client) may show the entire URL of the
>  hyperlink as a tooltip (see attached screenshot).  Is there a way to show
>  something nicer / smaller?  In the attached screenshot, either no tooltip
>  or a tooltip showing "Drill down to all 1.2.7a results" would be nice.
> 
> -- 
> Ticket URL: 
> MTT 
> Issue tracking for the MPI Testing Tool.
> 

Re: [MTT devel] Tracking process stats

[Ethan Mallove]

On Tue, Apr/22/2008 01:35:06PM, Josh Hursey wrote:
> On the Open MPI teleconf this morning Rich mentioned that
> he was  noticing odd memory usage. It got me thinking,
> would it be useful for MTT to track important aspects of
> the process such as memory use?
>
> Just a thought. I'm not exactly sure how we would report
> or record  this, but if it is useful we can file a bug for
> it :)
> 

Would this require a new "memory-usage" test suite? Or were
you thinking more along the lines of a new integer column in
the test_run table to record memory usage for *every* test
run?

-Ethan


> Cheers,
> Josh
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] Tracking process stats

[Ethan Mallove]

On Tue, Apr/22/2008 03:19:35PM, Jeff Squyres wrote:
> Gathering the info from any given might be a little difficult -- we'd  
> have to enlist orte somehow.  The orteds could conceivably be able to  
> get this info because the MPI processes are their children, after  
> all.  The orteds would then need to gather this info and make it  
> available somehow (e.g., mpirun could dump out a file, or perhaps  
> something to stdout, ...etc.).
> 

What about using Proc::ProcessTable or the "ps" command?

  http://www.perlmonks.org/?node_id=115098

I'm guessing this would be difficult because of processes
on remote nodes?

-Ethan


> 
> On Apr 22, 2008, at 3:16 PM, Josh Hursey wrote:
> 
> > I was thinking for very test as an extra bit or two of information.
> > But we could try a test suite too, but we would have to think about
> > what we would want to exercise in it.
> >
> > -josh
> >
> > On Apr 22, 2008, at 1:45 PM, Ethan Mallove wrote:
> >
> >> On Tue, Apr/22/2008 01:35:06PM, Josh Hursey wrote:
> >>> On the Open MPI teleconf this morning Rich mentioned that
> >>> he was  noticing odd memory usage. It got me thinking,
> >>> would it be useful for MTT to track important aspects of
> >>> the process such as memory use?
> >>>
> >>> Just a thought. I'm not exactly sure how we would report
> >>> or record  this, but if it is useful we can file a bug for
> >>> it :)
> >>>
> >>
> >> Would this require a new "memory-usage" test suite? Or were
> >> you thinking more along the lines of a new integer column in
> >> the test_run table to record memory usage for *every* test
> >> run?
> >>
> >> -Ethan
> >>
> >>
> >>> Cheers,
> >>> Josh
> >>>
> >>> ___
> >>> mtt-devel mailing list
> >>> mtt-de...@open-mpi.org
> >>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
> >> ___
> >> mtt-devel mailing list
> >> mtt-de...@open-mpi.org
> >> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
> >
> > ___
> > mtt-devel mailing list
> > mtt-de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
> 
> 
> -- 
> Jeff Squyres
> Cisco Systems
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] bogus timestamps in database

[Ethan Mallove]

On Thu, Jul/17/2008 04:35:38PM, Jeff Squyres wrote:
> Here's a fun report (as of 17 July 2008):
>
> http://www.open-mpi.org/mtt/index.php?do_redir=775
>
> Note that two of the rows are in the future.  :-)  (Absoft has since fixed 
> the problem; ntp accidentally got turned off)
>
> Ethan and I talked about this a bit, and then Josh and I talked about it.  
> Posting here to summarize everything:
>
> - It seems like a good solution for the moment is for submit.php to examine 
> all the timestamps in a given submit and compare them to now().  Find the 
> timestamp that latest in time, and compute x=latest_timestamp - now().  If 
> x>0, then subtract x from *all* timestamps in the submitted data.  Then 
> print a Big Hairy Warning on the client that their time is not coordinated 
> with the server.
>
> - Josh thinks that we should have a larger conversation about how to have 
> some values be regulated (e.g., MPI name, test suite name, etc.).  I agree 
> -- classic case: some people call it "intel", others call it "intel suite". 
>  They show up differently in the DB.  My $0.02 is that we should allow 
> people to call it whatever they want in the .ini file, but then somehow 
> ensure to submit the names all consistently (e.g., ini file has a map of 
> "this ini section is reported as 'intel'"), and if the name is invalid, 
> reject the data from the DB (or maybe put it in "quarrantine" so that it 
> can be cleaned up and put in the main DB)?
>

It's a neccessity that the INI section naming be flexible.
E.g., I have intel-32 and intel-64 sections to test 32-bit
and 64-bit. Note, there's no way around this because the
Perl INI parser we're using does not allow duplicate section
names, and also, MTT constructs a scratch tree on the
assumption that each section has a unique name.

For "database text string regulation", there's also:

  http://svn.open-mpi.org/trac/mtt/ticket/7 (users should be
  able to delete or modify results from database)

-Ethan

> -- 
> Jeff Squyres
> Cisco Systems
>
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] [MTT svn] svn:mtt-svn r1216

[Ethan Mallove]

Nice!

Which device(s) does DiskFree.pm check for space on? I
occasionally run out of room in /tmp, so I would want it to
check my swap space.

Can we remove these? (All but the .pm and README files.)

 trunk/lib/Filesys/Changes
 trunk/lib/Filesys/MANIFEST
 trunk/lib/Filesys/Makefile.PL
 trunk/lib/Filesys/eg/
 trunk/lib/Filesys/eg/perldf
 trunk/lib/Filesys/eg/silly
 trunk/lib/Filesys/test.pl

-Ethan

On Tue, Jul/22/2008 09:27:04PM, jsquy...@osl.iu.edu wrote:
> Author: jsquyres
> Date: 2008-07-22 21:27:04 EDT (Tue, 22 Jul 2008)
> New Revision: 1216
> URL: https://svn.open-mpi.org/trac/mtt/changeset/1216
> 
> Log:
> Fixes #370: have MTT exit if there isn't enough disk space left.
> 
> Added:
>trunk/lib/Filesys/
>trunk/lib/Filesys/Changes
>trunk/lib/Filesys/DiskFree.pm
>trunk/lib/Filesys/MANIFEST
>trunk/lib/Filesys/Makefile.PL
>trunk/lib/Filesys/README
>trunk/lib/Filesys/README.mtt
>trunk/lib/Filesys/eg/
>trunk/lib/Filesys/eg/perldf   (contents, props changed)
>trunk/lib/Filesys/eg/silly   (contents, props changed)
>trunk/lib/Filesys/test.pl
> Text files modified: 
>trunk/client/mtt |11   
>   
>trunk/lib/MTT/Globals.pm | 5 +++   
>   
>trunk/lib/MTT/MPI/Get.pm | 2   
>   
>trunk/lib/MTT/MPI/Install.pm | 4 +-
>   
>trunk/lib/MTT/Test/Build.pm  | 4 +-
>   
>trunk/lib/MTT/Test/Get.pm| 2   
>   
>trunk/lib/MTT/Test/Run.pm| 4 +-
>   
>trunk/lib/MTT/Test/RunEngine.pm  | 6 ++--  
>   
>trunk/lib/MTT/Util.pm|50 
> ++- 
>trunk/samples/ompi-core-template.ini |17 + 
>   
>10 files changed, 86 insertions(+), 19 deletions(-)
> 
> Modified: trunk/client/mtt
> ==
> --- trunk/client/mtt  (original)
> +++ trunk/client/mtt  2008-07-22 21:27:04 EDT (Tue, 22 Jul 2008)
> @@ -112,6 +112,7 @@
>  use MTT::Values;
>  use MTT::Timer;
>  use MTT::Util;
> +use Filesys::DiskFree;
>  
>  my @file_arg;
>  my $stdin_arg;
> @@ -492,31 +493,31 @@
>  MTT::Reporter::Init($ini);
>  }
>  
> -if ($mpi_get && !MTT::Util::find_terminate_file()) {
> +if ($mpi_get && !MTT::Util::time_to_terminate()) {
>  ::Timer::start($time_phases);
>  MTT::MPI::Get::Get($ini, $source_dir, $force_arg);
>  ::Timer::stop();
>  ::Timer::print("Phase: MPI Get", $time_phases, 1);
>  }
> -if ($mpi_install && !MTT::Util::find_terminate_file()) {
> +if ($mpi_install && !MTT::Util::time_to_terminate()) {
>  ::Timer::start($time_phases);
>  MTT::MPI::Install::Install($ini, $ini_full, $install_dir, 
> $force_arg);
>  ::Timer::stop();
>  ::Timer::print("Phase: MPI Install", $time_phases, 1);
>  }
> -if ($test_get && !MTT::Util::find_terminate_file()) {
> +if ($test_get && !MTT::Util::time_to_terminate()) {
>  ::Timer::start($time_phases);
>  MTT::Test::Get::Get($ini, $source_dir, $force_arg);
>  ::Timer::stop();
>  ::Timer::print("Phase: Test Get", $time_phases, 1);
>  }
> -if ($test_build && !MTT::Util::find_terminate_file()) {
> +if ($test_build && !MTT::Util::time_to_terminate()) {
>  ::Timer::start($time_phases);
>  MTT::Test::Build::Build($ini, $ini_full, $install_dir, $force_arg);
>  ::Timer::stop();
>  ::Timer::print("Phase: Test Build", $time_phases, 1);
>  }
> -if ($test_run && !MTT::Util::find_terminate_file()) {
> +if ($test_run && !MTT::Util::time_to_terminate()) {
>  ::Timer::start($time_phases);
>  MTT::Test::Run::Run($ini, $ini_full, $install_dir, $runs_data_dir,
>  $force_arg);
> 
> Added: trunk/lib/Filesys/Changes
> ==
> --- (empty file)
> +++ trunk/lib/Filesys/Changes 2008-07-22 21:27:04 EDT (Tue, 22 Jul 2008)
> @@ -0,0 +1,27 @@
> +Revision history for Perl extension Filesys::DiskFree.
> +
> +0.06   Fri Oct 23 18:26:19 EDT 1998
> + - Now supports HP-UX, thanks to Richard Paul for the patch.
> +
> +0.05   Wed Aug 26 23:54:15 EDT 1998
> + - Now supports OSF/1, thanks to Eric Foster-Johnson for the details.
> +
> +0.04   Sat Aug  1 12:15:42 EDT 1998
> + - Fixes problem if passed a barefilename, without any '/'.
> + - Bug fix in 'silly' example, accidentally deleted a ;
> + - perldf now works on filesystems with 0% free (eg psuedo-fs), and
> +   formats filesystems with <10% free 

Re: [MTT devel] mpi_details section with different scenarios for command line params

[Ethan Mallove]

On Mon, Nov/03/2008 09:34:07AM, Mike Dubman wrote:
>Hello Guys, 
>
>Please suggest the proper way to handle the following:
> 
>Is there any way to run "test run" section with a list
>of "mpi_details" sections?

Mike,

There is currently no way to iterate over multiple
mpi_details sections, but there might be an acceptable
workaround. You can create a simple wrapper script to
iterate over variations of your MPI details section using
command line INI file overrides (see
https://svn.open-mpi.org/trac/mtt/wiki/INIOverrides). E.g.,
say you have the following MPI details section:

  [MPI details: Open MPI]
  foo = some default value
  bar = some default value
  exec = mpirun @foo@ @bar@ ...

Using command-line INI overrides, you can iterate over a
series of values for "foo" and/or "bar":

  $ client/mtt --scratch /some/dir ...
  $ client/mtt --scratch /some/dir --test-run foo=abc ...
  $ client/mtt --scratch /some/dir --test-run foo=def ...
  $ client/mtt --scratch /some/dir --test-run bar=uvw ...
  $ client/mtt --scratch /some/dir --test-run bar=xyz ...
  ...

Note in the above example, we use the same scratch directory
for all the runs, and we run only the test run phase (via
the --test-run option) since we do not need to reinstall or
rebuild anything as we iterate over different command lines.

Could the above be of use for what you're trying to do?

-Ethan


> 
>Or how to execute specific "Test run" section against
>specific "mpi_details" section, where "mpi_details" can
>have many different scenarios of command line
>parameters (i.e. single mpi_details should be executed
>a number of times equal to the number of available
>scenarios for this mpi_details)? Is that possible? (it
>is similar to the @np param treatment available inside
>mpi_details section)
> 
>Thanks
> 
>Mike.

> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] Time to make the 2009 mtt database partitions?

[Ethan Mallove]

On Mon, Dec/01/2008 11:52:09AM, Josh Hursey wrote:
> I just created the partitions and updated the scripts so they Grant the 
> proper permissions after creating the tables.
>
> I also updated the wiki to document how to add these new tables:
>   
> https://svn.open-mpi.org/trac/mtt/wiki/ServerMaintenance#YearlyMaintenance
>
> So we should be all set for 2009 :)

Thanks Josh!

-Ethan

>
> Cheers,
> Josh
>
> On Dec 1, 2008, at 11:06 AM, Josh Hursey wrote:
>
>> Good catch. I have a reminder email set to be sent out later this month 
>> regarding this so we don't hit the same problem we had last year. But we 
>> should probably do it now so we don't forget later.
>>
>> There is a script here:
>> server/sql/support/create-partitions.sh
>>
>> This will generate SQL files for all of the tables and indexes that we 
>> need. For 2009 it looks something like (XX is a short-cut for all months):
>> ./create-partitions-mpi-install.pl 2009 XX >  2009-mpi-install.sql
>> ./create-partitions-test-build.pl 2009 XX >  2009-test-build.sql
>> ./create-partitions-test-run.pl 2009 XX >  2009-test-run.sql
>> ./create-partition-indexes.pl 2009 XX >  2009-indexes.sql
>>
>> Then just run the generated SQL scripts into the database to create the 
>> tables.
>>
>> I can do this today, and send an email when it is done. I'll also add some 
>> documentation about this to the Wiki.
>>
>> Thanks,
>> Josh
>>
>> On Dec 1, 2008, at 10:07 AM, Ethan Mallove wrote:
>>
>>> Folks,
>>>
>>> \dt doesn't show any 2009 tables in the "mtt" Postgres database. Will
>>> the following commands (using 0-11) set us up for 2009?
>>>
>>> $ server/sql/support/create-partitions-mpi-install.pl 2009 00
>>> $ server/sql/support/create-partitions-mpi-install.pl 2009 01
>>> $ server/sql/support/create-partitions-mpi-install.pl 2009 02
>>> ...
>>> $ server/sql/support/create-partitions-test-build.pl 2009 00
>>> $ server/sql/support/create-partitions-test-build.pl 2009 01
>>> $ server/sql/support/create-partitions-test-build.pl 2009 02
>>> ...
>>> $ server/sql/support/create-partitions-test-run.pl 2009 00
>>> $ server/sql/support/create-partitions-test-run.pl 2009 01
>>> $ server/sql/support/create-partitions-test-run.pl 2009 02
>>> ...
>>>
>>> -Ethan
>>> ___
>>> mtt-devel mailing list
>>> mtt-de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] MTT on Windows

[Ethan Mallove]

On Wed, Mar/11/2009 03:47:22PM, Jeff Squyres wrote:
> Thanks for your patience!  Yes, this looks good to me with one minor nit:
>
>> +if(($sys_type == "Cygwin" || $sys_type == "Msys") &&
>> +$config->{compiler_name} == "microsoft") {
>
> should be
>
>> +if(($sys_type eq "Cygwin" || $sys_type eq "Msys") &&
>> +$config->{compiler_name} eq "microsoft") {
>
> Josh / Ethan -- got any comments for Shiqing?

I just noticed last night's CYGWIN results. Nice!

Should a regexp (see below) be used in case the sys_type comes back as, e.g.,
"cygwin", "CYGWIN", "cygwin-2.0", etc.?

  $sys_type =~ /cygwin/i

Other than that, it looks good to me.

-Ethan

>
>
>
>
> On Mar 11, 2009, at 2:58 PM, Shiqing Fan wrote:
>
>> Hi Jeff,
>>
>>
>> Sorry for the carelessness. This time it looks better? :-)
>>
>>
>> Thanks,
>> Shiqing
>> >
>> > Can you double check your cr / cr/lf settings?  It looks like you're
>> > committing in the windows format -- can you convert and commit in the
>> > unix format?  That way, it wouldn't look like the entire
>> > GNU_Install.pm file is being replaced, for example.
>> >
>> > I forgot to mention in my last mail -- since cmake *only* works on
>> > Windows and our Autotools system *doesn't* work on Windows, I retract
>> > my earlier statement: don't bother with an ompi_cmake parameter in the
>> > .ini file.  Just have OMPI.pm figure out if you're on cygwin or mingw
>> > and call the right back-end building function.
>> >
>> > Also, in Do_Step.pm, you might want to remove the "_" prefix from the
>> > sub names.  "_" as a prefix in perl is meant to imply that it's a
>> > private variable/method.
>> >
>> > Finally, in Do_Step.pm, do you have two _do_step() functions?
>> >
>>
>> Index: lib/Filesys/DiskFree.pm
>> ===
>> --- lib/Filesys/DiskFree.pm  (revision 1271)
>> +++ lib/Filesys/DiskFree.pm  (working copy)
>> @@ -29,6 +29,16 @@
>>  'inodes' => "df -Pi",
>>  'format' => "linuxish",
>> },
>> +'cygwin' => {
>> +'blocks' => "df -P",
>> +'inodes' => "df -Pi",
>> +'format' => "linuxish",
>> +},
>> +'msys' => {
>> +'blocks' => "df -P",
>> +'inodes' => "df -Pi",
>> +'format' => "linuxish",
>> +},
>> 'solaris' =>  {
>>  'blocks' => "df -k",
>>  'inodes' => "df -k -o i -F ufs",
>> Index: lib/MTT/Common/Cmake.pm
>> ===
>> --- lib/MTT/Common/Cmake.pm  (revision 0)
>> +++ lib/MTT/Common/Cmake.pm  (revision 0)
>> @@ -0,0 +1,77 @@
>> +#!/usr/bin/env perl
>> +#
>> +# Copyright (c) 2005-2006 The Trustees of Indiana University.
>> +# All rights reserved.
>> +# Copyright (c) 2006-2008 Cisco Systems, Inc.  All rights reserved.
>> +# Copyright (c) 2007-2008 Sun Microsystems, Inc.  All rights reserved.
>> +# Copyright (c) 2009  High Performance Computing Center Stuttgart,
>> +# University of Stuttgart.  All rights reserved.
>> +# $COPYRIGHT$
>> +#
>> +# Additional copyrights may follow
>> +#
>> +# $HEADER$
>> +#
>> +
>> +package MTT::Common::Cmake;
>> +my $package = ModuleName(__PACKAGE__);
>> +
>> +use strict;
>> +use MTT::Messages;
>> +use MTT::Values;
>> +use MTT::Common::Do_step;
>> +
>> +#--
>> +
>> +# Do the following steps:
>> +#   [ ] cmake -G "generator" -D configure_arguments source_path
>> +#   [ ] devenv OpenMPI.sln /build
>> +sub Install {
>> +my ($config) = @_;
>> +
>> +my $x;
>> +my $result_stdout;
>> +my $result_stderr;
>> +
>> +# Prepare $ret
>> +my $ret;
>> +$ret->{test_result} = MTT::Values::FAIL;
>> +$ret->{exit_status} = 0;
>> +
>> +# On windows, do the following steps:
>> +
>> +# prepare the windows style prefix.
>> +# replace '/cygdrive/x/' with 'x:/'
>> +my $win_prefix = substr ($config->{installdir},10,1) . ":" . substr 
>> ($config->{installdir},11);
>> +
>> +# generate Visual Studio solution files
>> +# use 'script' to redirect MS command output
>> +$x = MTT::Common::Do_step::do_step($config,
>> +"script -a -c \"cmake 
>> $config->{configure_arguments} -D CMAKE_INSTALL_PREFIX:PATH=$win_prefix 
>> .\" -f temp.txt",
>> +$config->{merge_stdout_stderr});
>> +
>> +# Overlapping keys in $x override $ret
>> +%$ret = (%$ret, %$x);
>> +return $ret if (!MTT::DoCommand::wsuccess($ret->{exit_status}));
>> +
>> +# compile the whole solution
>> +$x = MTT::Common::Do_step::do_step($config, "script -a -c 
>> \"devenv.com *.sln /build debug\" -f temp.txt",
>> +$config->{merge_stdout_stderr});
>> +%$ret = (%$ret, %$x);
>> +return $ret if (!MTT::DoCommand::wsuccess($ret->{exit_status}));
>> +
>> +# install to the prefix dir
>> +$x = MTT::Common::Do_step::do_step($config, 

Re: [MTT devel] GSOC application

[Ethan Mallove]

On Wed, Mar/18/2009 03:28:48PM, Josh Hursey wrote:
> So they posted the list of accepted projects and we are -not- on it
> for this year:
>
>   http://socghop.appspot.com/program/accepted_orgs/google/gsoc2009
>
> Maybe next year. I don't know if they will be sending around a note
> regarding why we were not selected to participate. If they do I will
> forward it along.

Thanks, Josh.

I'm reading that in 2008, they only accepted 174 out of the 7100
applications.

-Ethan

>
> Cheers,
> Josh
>
> On Mar 13, 2009, at 3:19 PM, Jeff Squyres wrote:
>
>> Awesome; many thanks for carrying the baton over the finish line, Josh!
>>
>> On Mar 13, 2009, at 2:56 PM, Josh Hursey wrote:
>>
>>> The application has been submitted. We find out on March 18 (3 pm) if
>>> we have been accepted. Link to timeline below:
>>>http://socghop.appspot.com/document/show/program/google/gsoc2009/
>>> timeline
>>>
>>> Cheers,
>>> Josh
>>>
>>> On Mar 13, 2009, at 2:19 PM, Josh Hursey wrote:
>>>
>>> > I just pushed a final draft to the repository. I'll probably plan
>>> > on submitting at 2:30/2:45. Let me know if you have any edits
>>> > before then either through email or IM.
>>> >
>>> > Cheers,
>>> > Josh
>>> >
>>> > On Mar 13, 2009, at 12:11 PM, Josh Hursey wrote:
>>> >
>>> >> I finished a first pass at cleaning up the Ideas page on the Wiki.
>>> >> All of the ideas were preserved, just some rewording and formatting.
>>> >>   https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas
>>> >>
>>> >> If you get a chance, read through this and make sure the text
>>> >> sounds ok (feel free to clean the text up as necessary).
>>> >>
>>> >> The application is due by 3 pm EST. So I hope to have the
>>> >> application ready by 2ish. I'll move onto the application itself now.
>>> >>
>>> >> -- Josh
>>> >>
>>> >> On Mar 12, 2009, at 4:43 PM, Josh Hursey wrote:
>>> >>
>>> >>> Jeff is going to take the first pass at the application.
>>> >>>
>>> >>> I am going to go through the Idea page on the wiki and polish a bit:
>>> >>>   https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas
>>> >>>
>>> >>> I'll let folks know when I'm done, and we can start iterating on
>>> >>> drafts.
>>> >>>
>>> >>> Cheers,
>>> >>> Josh
>>> >>>
>>> >>> On Mar 12, 2009, at 4:08 PM, Jeff Squyres wrote:
>>> >>>
>>>  I've created a quick-n-dirty hg to collaborate on the GSOC
>>>  application.  There's a web form to fill out to apply, so let's
>>>  work on a .txt file in the hg to get it right.
>>> 
>>>  We have until 3pm US Eastern time tomorrow to submit.  Here's
>>>  the HG:
>>> 
>>> ssh://www.open-mpi.org/~jsquyres/hg/gsoc/
>>> 
>>>  I've put the PDF there for now; I'll kruft up a quick .txt
>>>  shortly and push it there as well.
>>> 
>>>  --
>>>  Jeff Squyres
>>>  Cisco Systems
>>> 
>>>  ___
>>>  mtt-devel mailing list
>>>  mtt-de...@open-mpi.org
>>>  http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>> >>>
>>> >>> ___
>>> >>> mtt-devel mailing list
>>> >>> mtt-de...@open-mpi.org
>>> >>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>> >>
>>> >> ___
>>> >> mtt-devel mailing list
>>> >> mtt-de...@open-mpi.org
>>> >> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>> >
>>> > ___
>>> > mtt-devel mailing list
>>> > mtt-de...@open-mpi.org
>>> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>>
>>> ___
>>> mtt-devel mailing list
>>> mtt-de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>>
>> -- 
>> Jeff Squyres
>> Cisco Systems
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] [MTT svn] svn:mtt-svn r1273 (Analyze/Performance plug-ins)

[Ethan Mallove]

On Thu, Mar/19/2009 09:17:29PM, Mike Dubman wrote:
>Hello Eithan,
>Thanks for info, will refactor it.
> 
>from http://www.netlib.org/benchmark/hpl/
> 
>...
>HPL is a software package that solves a (random) dense linear
>system in double precision (64 bits) arithmetic on
>distributed-memory computers. It can thus be regarded as a
>portable as well as freely available implementation of the High
>Performance Computing Linpack Benchmark.
> 
>The HPL package provides a testing and timing program to quantify
>the accuracy of the obtained solution as well as the time it took
>to compute it
>...
> 
>Where do you think is a good place to keep parsers for other then
>lat/bw based mpi benchmarks? I think we can have a collection of
>such parsers in the mtt and at some point we can enhance mtt
>reports with other metrics.
> 
>What do you think?

Sounds like a nice enhancement.  I think just assigning this parser
its own "test_type" will be helpful for now (and I have no thoughts on
what to call it).  When the server-side submit PHP script is ready to
handle non-latency/bandwidth test data, we can split out the
client-side Analyze/Performance directory.

-Ethan


> 
>On Thu, Mar 19, 2009 at 8:22 PM, Ethan Mallove <ethan.mall...@sun.com>
>wrote:
> 
>  Hi Mike,
> 
>  Is HPL a latency and/or bandwidth performance test? *All the Analyze
>  plug-ins in lib/MTT/Test/Analyze/Performance are for latency/bandwidth
>  tests, which means they can then be rendered as graphs in the MTT
>  Reporter. *All of these plug-ins are required to output at least one
>  of the following:
> 
>  *latency_avg
>  *latency_min
>  *latency_max
>  *bandwidth_avg
>  *bandwidth_min
>  *bandwidth_max
> 
>  They all contain this:
> 
>  *$report->{test_type} = 'latency_bandwidth';
> 
>  HPL.pm should have a line like this somewhere:
> 
>  *$report->{test_type} = 'tv_gflops';
> 
>  Maybe HPL.pm could go into a different directory or have a comment
>  somewhere to clear up this confusion.
> 
>  Regards,
>  Ethan
> 
>  On Thu, Mar/19/2009 02:11:05AM, mi...@osl.iu.edu wrote:
>  > Author: miked
>  > Date: 2009-03-19 02:11:04 EDT (Thu, 19 Mar 2009)
>  > New Revision: 1273
>  > URL: https://svn.open-mpi.org/trac/mtt/changeset/1273
>  >
>  > Log:
>  > HPL analyzer added
>  >
>  > Added:
>  > * *trunk/lib/MTT/Test/Analyze/Performance/HPL.pm
>  >
>  > Added: trunk/lib/MTT/Test/Analyze/Performance/HPL.pm
>  >
>  
> ==
>  > --- (empty file)
>  > +++ trunk/lib/MTT/Test/Analyze/Performance/HPL.pm * * 2009-03-19
>  02:11:04 EDT (Thu, 19 Mar 2009)
>  > @@ -0,0 +1,63 @@
>  > +#!/usr/bin/env perl
>  > +#
>  > +# Copyright (c) 2006-2007 Sun Microsystems, Inc. *All rights
>  reserved.
>  > +# Copyright (c) 2007 * * *Voltaire *All rights reserved.
>  > +# $COPYRIGHT$
>  > +#
>  > +# Additional copyrights may follow
>  > +#
>  > +# $HEADER$
>  > +#
>  > +
>  > +package MTT::Test::Analyze::Performance::HPL;
>  > +use strict;
>  > +use Data::Dumper;
>  > +#use MTT::Messages;
>  > +
>  > +# Process the result_stdout emitted from one of hpl tests
>  > +sub Analyze {
>  > +
>  > + * *my($result_stdout) = @_;
>  > + * *my $report;
>  > + * *my(@t_v,
>  > + * * * @time,
>  > + * * * @gflops);
>  > +
>  > +$report->{test_name}="HPL";
>  > + * *my @lines = split(/\n|\r/, $result_stdout);
>  > + * *# Sample result_stdout:
>  > +#- The matrix A is randomly generated for each test.
>  > +#- The following scaled residual check will be computed:
>  > +# * * *||Ax-b||_oo / ( eps * ( || x ||_oo * || A ||_oo + || b ||_oo )
>  * N )
>  > +#- The relative machine precision (eps) is taken to be * * * * * * *
>  1.110223e-16
>  > +#- Computational tests pass if scaled residuals are less than * * * *
>  * * * *16.0
>  >
>  
> +#
>  > +#T/V * * * * * * * *N * *NB * * P * * Q * * * * * * * Time * * * * *
>  * * * Gflops
>  >
>  
> +#---

Re: [MTT devel] GSOC application

[Ethan Mallove]

on't see the models.py attachment.

Thanks,
Ethan


>  You can run the attached example in the google datastore dev
>  environment. (http://code.google.com/appengine/downloads.html)
> 
>  Please comment.
> 
>  Thanks
>  Mike
> 
>  On Tue, Mar 24, 2009 at 12:17 AM, Jeff Squyres <jsquy...@cisco.com>
>  wrote:
> 
>On Mar 23, 2009, at 9:05 AM, Ethan Mallove wrote:
> 
>  *---+-+--
>  *Resource * * * * * | Unit * * * * * * * *| Unit cost
>  *---+-+--
>  *Outgoing Bandwidth | gigabytes * * * * * | $0.12
>  *Incoming Bandwidth | gigabytes * * * * * | $0.10
>  *CPU Time * * * * * | CPU hours * * * * * | $0.10
>  *Stored Data * * * *| gigabytes per month | $0.15
>  *Recipients Emailed | recipients * * * * *| $0.0001
>  *---+-+--
> 
>  Would we itemize the MTT bill on a per user basis? *E.g., orgs that
>  use MTT more, would have to pay more?
> 
>Let's assume stored data == incoming bandwidth, because we never throw
>anything away. *And let's go with the SWAG of 100GB. *We may or may
>not be able to gzip the data uploading to the server. *So if anything,
>we *might* be able to decrease the incoming data and have higher level
>of stored data.
> 
>I anticipate our outgoing data to be significantly less, particularly
>if we can gzip the outgoing data (which I think we can). *You're
>right, CPU time is a mystery -- we won't know what it will be until we
>start running some queries to see what happens.
> 
>100GB * $0.10 = $10
>100GB * $0.15 = $15
>total = $25 for the first month
> 
>So let's SWAG at $25/mo for a year = $300. *This number will be wrong
>for several reasons, but it at least gives us a ballpark. *For
>$300/year, I think we (the OMPI project) can find a way to pay for
>this fairly easily.
>--
>Jeff Squyres
>Cisco Systems
> 
>___
>mtt-devel mailing list
>mtt-de...@open-mpi.org
>http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
> 
> References
> 
>Visible links
>. mailto:mike.o...@gmail.com
>. http://code.google.com/appengine/downloads.html
>. mailto:jsquy...@cisco.com
>. mailto:mtt-de...@open-mpi.org
>. http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] GSOC application

[Ethan Mallove]

On Tue, Apr/14/2009 09:27:14PM, Mike Dubman wrote:
>On Tue, Apr 14, 2009 at 5:04 PM, Jeff Squyres <jsquy...@cisco.com> wrote:
> 
>  On Apr 13, 2009, at 2:08 PM, Mike Dubman wrote:
> 
>Hello Ethan,
> 
>  Sorry for joining the discussion late... I was on travel last week and
>  that always makes me waaay behind on my INBOX. *:-(
> 
>    On Mon, Apr 13, 2009 at 5:44 PM, Ethan Mallove <ethan.mall...@sun.com>
>wrote:
> 
>Will this translate to something like
>lib/MTT/Reporter/GoogleDatabase.pm? *If we are to move away from the
>current MTT Postgres database, we want to be able to submit results to
>both the current MTT database and the new Google database during the
>transition period. Having a GoogleDatabase.pm would make this easier.
> 
>I think we should keep both storage options: current postgress and
>datastore. The mtt changes will be minor to support datastore.
>Due that fact that google appengine API (as well as datastore API) can
>be python or java only, we will create external scripts to manipulate
>datastore objects:
> 
>  Ah, good point (python/java not perl). *But I think that
>  lib/MTT/Reporter/GoogleDataStore.pm could still be a good thing -- we
>  have invested a lot of time/effort into getting our particular mtt
>  clients setup just the way we want them, setting up INI files,
>  submitting to batch schedulers, etc.
> 
>  A GoogleDataStore.pm reporter could well fork/exec a python/java
>  executable to do the actual communication/storing of the data, right...?
>  *More below.
> 
>completely agree, once we have external python/java/cobol scripts to
>manipulate GDS objects, we should wrap it by perl and call from MTT in
>same way like it works today for submitting to the postgress.
> 
>*
> 
>The mtt will dump test results in xml format. Then, we provide two
>python (or java?) scripts:
> 
>mtt-results-submit-to-datastore.py - script will be called at the end
>of mtt run and will read xml files, create objects and save to
>datastore
> 
>  Could be pretty easy to have a Reporter/GDS.pm (I keep making that
>  filename shorter, don't I? :-) ) that simply invokes the
>  mtt-result-submit-to-datastore.pt script on the xml that it dumped for
>  that particular test.
> 
>  Specifically: I do like having partial results submitted while my MTT
>  tests are running. *Cisco's testing cycle is about 24 hours, but groups
>  of tests are finishing all the time, so it's good to see those results
>  without having to wait the full 24 hours before anything shows up. *I
>  guess that's my only comment on the idea of having a script that
>  traverses the MTT scratch to find / submit everything -- I'd prefer if
>  we kept the same Reporter idea and used an underlying .py script to
>  submit results as they become ready.
> 
>  Is this do-able?
> 
>sounds good, we should introduce some guid (like pid) for mtt session,
>where all mtt results generated by this session will be referring to this
>guid.* Later we use this guid to submit partial results as they become
>ready and connect it to the appropriate mtt session object (see models.py)
> 
>mtt-results-query.py - sample script to query datastore and generate
>some simple visual/tabular reports. It will serve as tutorial for
>howto access mtt data from scripts for reporting.
> 
>Later, we add another script to replace php web frontend. It will be
>hosted on google appengine machines and will provide web viewer for
>mtt results. (same way like index.php does today)
> 
>  Sounds good.
> 
>> * * *b. mtt_save_to_db.py - script which will go over mtt scratch
>dir, find
>> * * *all xml files generated for every mtt phase, parse it and save
>to
>> * * *datastore, preserving test results relations,i.e. all test
>results will
>> * * *be grouped by mtt general info: mpi version, name, date, 
>>
>> * * *c. same script can scan, parse and save from xml files
>generated by
>> * * *wrapper scripts for non mtt based executions (fluent, ..)
> 
>I'm confused here. *Can't MTT be outfitted to report results of a
>Fluent run?
> 
>I think we can enhance mtt to be not only mpi testing platform, but
>also to serve as mpi benchmarking platform. We can use datastore to
>keep mpi-based benchmarking results in the same manner 

Re: [MTT devel] GSOC application

[Ethan Mallove]

Dancing bears on slide 1. We're off to a good start.

-Ethan

On Wed, Apr/22/2009 09:11:57AM, Jeff Squyres wrote:
> The slides will also be on webex on the call tomorrow.  Use the URL to join 
> the meeting in the email invite that you got.  That URL will launch an 
> application thingy for the web portion of the meeting, and it will prompt 
> you for a phone number to call you to join the audio portion of the 
> meeting.  Mike will be transmitting his slides on the web portion (just 
> because we can / it's fun ;-) ).
>
>
> On Apr 22, 2009, at 8:39 AM, Mike Dubman wrote:
>
>> Hello guys,
>>
>> Here is a small ppt with MTToGDS summary for tomorrow`s meeting.
>> regards
>>
>> Mike
>>
>> On Thu, Apr 16, 2009 at 5:02 PM, Jeff Squyres  wrote:
>> Will there be dancing bears on the slides?  I'll only accept slides with 
>> dancing bears!
>>
>> ;-)
>>
>> (no need to be formal; if slides help, great, otherwise don't make slides 
>> just because we have webex available)
>>
>>
>>
>> On Apr 16, 2009, at 9:50 AM, Mike Dubman wrote:
>>
>> I will prepare ppt with summary of what were discussed and agreed, 
>> milestones, open questions and other thoughts.
>> regards
>>
>> Mike
>>
>> On Thu, Apr 16, 2009 at 2:07 PM, Jeff Squyres  wrote:
>> Ok, I think we converged on a time: 9am US Eastern / 4pm Israel next 
>> Thuesday, April 23.
>>
>> I'll send the webex invites in a separate email.  Mike: if you have slides 
>> or other electronic material to show during the call, we can use webex for 
>> that.  Otherwise, we can just use the telephone part of webex and ignore 
>> the web part.
>>
>>
>>
>> On Apr 15, 2009, at 4:18 PM, Josh Hursey wrote:
>>
>> I have been listening in on the thread, but have not had time to
>> really look at much (which is why I have not been replying). I'm
>> interested in listening in on the teleconf as well, though if I become
>> a blocker for finding a time feel free to cut me out.
>>
>> Best,
>> Josh
>>
>> On Apr 14, 2009, at 8:51 PM, Jeff Squyres wrote:
>>
>> >> BTW -- if it's useful to have a teleconference about this kind of
>> >> stuff, I can host a WebEx meeting.  WebEx has local dialins around
>> >> the world, including Israel...
>> >>
>> >>
>> >> sure, what about next week?
>> >
>> > I have a Doodle account -- let's try that to do the scheduling:
>> >
>> >http://doodle.com/gzpgaun2ef4szt29
>> >
>> > Ethan, Josh, and I are all in US Eastern timezone (I don't know if
>> > Josh will participate), so that might make scheduling *slightly*
>> > easier.  I started timeslots at 8am US Eastern and stopped as 2pm US
>> > Eastern -- that's already pretty late in Israel.  I also didn't list
>> > Friday, since that's the weekend in Israel.
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>>
>> -- 
>> Jeff Squyres
>> Cisco Systems
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>>
>> -- 
>> Jeff Squyres
>> Cisco Systems
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>
>
> -- 
> Jeff Squyres
> Cisco Systems
>
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] Check a v3.0 commit

[Ethan Mallove]

On Wed, Apr/29/2009 12:30:25PM, Jeff Squyres wrote:
> Can one of you guys sanity https://svn.open-mpi.org/trac/mtt/changeset/1283 
> before I move it to the 3.0 branch?
>
> It should save some testing cycles if the OMPI tarball hasn't changed 
> versions from one day to the next (and you start using the field 
> ompi_snapshot_version_file in your INI file).

Works for me. Just had to make sure to set force to "0" in my INI file.

-Ethan


>
> -- 
> Jeff Squyres
> Cisco Systems
>
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] Check a v3.0 commit

[Ethan Mallove]

On Wed, Apr/29/2009 02:34:54PM, Jeff Squyres wrote:
> On Apr 29, 2009, at 2:32 PM, Ethan Mallove wrote:
>
>>> Can one of you guys sanity https://svn.open-mpi.org/trac/mtt/changeset/1283
>>> before I move it to the 3.0 branch?
>>>
>>> It should save some testing cycles if the OMPI tarball hasn't changed
>>> versions from one day to the next (and you start using the field
>>> ompi_snapshot_version_file in your INI file).
>>
>> Works for me. Just had to make sure to set force to "0" in my INI file.
>
> What do you mean?  I tried it with and without setting the field and it 
> seemed to do what I intended -- are you saying that you had to set it to 0 
> to get it to ignore the field properly?

I meant ompi_snapshot_version_file works correctly. Having "force" set
to "1" in my INI file overrode the ompi_snapshot_version_file param,
which is what was supposed to happen. Setting "force" to "0" made MTT
actually skip a tarball when the ompi_snapshot_version_file matched
the downloaded latest_snapshot.txt file.

-Ethan

>
> -- 
> Jeff Squyres
> Cisco Systems
>
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

[MTT devel] MTT email timeout notification feature

[Ethan Mallove]

Folks,

I came up with a feature, which does not seem quite appropriate to go
into the MTT trunk, but is still possibly useful for someone other
than me. I have posted a note about it on the MTT wiki:

  http://svn.open-mpi.org/trac/mtt/wiki/EmailTimeoutNotification

Here's the text of the Wiki page:

We (Sun) were trying to track down a hang in an MPI test that we were
seeing in our MTT runs which was difficult to reproduce manually. The
problem is that MTT kills the hanging process before a developer has a
chance to investigate the issue. To address this, I patched an MTT
client (see attached patch file) to send out a notification email
containing an mpirun command line and GDB back trace for the hanging
test. A predefined sentinel file is touched, which can later be
removed to force MTT to move on and continue testing. Here are the INI
parameters to activate the timeout email notification:

 * {{{docommand_timeout_sentinel_file}}}
 * {{{docommand_timeout_email_recipient}}}

Example usage:

{{{
$ client/mtt --scratch /foo/bar --file foo.ini
  
docommand_timeout_sentinel_file=/tmp/mtt-timeout-sentinel-file-\_string\(10\)
  docommand_timeout_email_recipient=fred.flints...@sun.com,barney.rub...@sun.com
}}}

-Ethan

Re: [MTT devel] MTT email timeout notification feature

[Ethan Mallove]

In r1300, I incorporated your notes, except for #2 and #3. I dug
around for a CPAN module for stack traces, but couldn't find anything.
Maybe MTT could contain a stripped down version of GDB for the sole
purpose of gathering stack traces? Or is there some other open source
"stack trace grabber" tool out there?

-Ethan

On Mon, Jun/22/2009 07:37:16AM, Jeff Squyres wrote:
> Actually, I think this would be fine for the trunk.  Some random notes:
>
> 1. It might be nice to move this logic out of the docommand sub itself and 
> into its own sub.
> 2. it would also be good to generalize the ps and gdb commands for systems 
> where those variants are not relevant
> 3. it might even be good to generally develop the backtrace functionality 
> overall -- backtraces would be really good to capture in the database...
> 4. how about having a[n optional] timeout with the sentinel file?  that is, 
> it'll send a mail, then wait another timeout (e.g., 1 hour) and if the 
> sentinel file still exists, mtt will remove the file and keep going
>
>
> On Jun 19, 2009, at 2:47 PM, Ethan Mallove wrote:
>
>> Folks,
>>
>> I came up with a feature, which does not seem quite appropriate to go
>> into the MTT trunk, but is still possibly useful for someone other
>> than me. I have posted a note about it on the MTT wiki:
>>
>>   http://svn.open-mpi.org/trac/mtt/wiki/EmailTimeoutNotification
>>
>> Here's the text of the Wiki page:
>>
>> We (Sun) were trying to track down a hang in an MPI test that we were
>> seeing in our MTT runs which was difficult to reproduce manually. The
>> problem is that MTT kills the hanging process before a developer has a
>> chance to investigate the issue. To address this, I patched an MTT
>> client (see attached patch file) to send out a notification email
>> containing an mpirun command line and GDB back trace for the hanging
>> test. A predefined sentinel file is touched, which can later be
>> removed to force MTT to move on and continue testing. Here are the INI
>> parameters to activate the timeout email notification:
>>
>>  * {{{docommand_timeout_sentinel_file}}}
>>  * {{{docommand_timeout_email_recipient}}}
>>
>> Example usage:
>>
>> {{{
>> $ client/mtt --scratch /foo/bar --file foo.ini
>>   
>> docommand_timeout_sentinel_file=/tmp/mtt-timeout-sentinel-file-\_string\(10\)
>>   
>> docommand_timeout_email_recipient=fred.flints...@sun.com,barney.rub...@sun.com
>> }}}
>>
>> -Ethan
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>
>
> -- 
> Jeff Squyres
> Cisco Systems
>
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] use of ()

[Ethan Mallove]

On Mon, Jul/06/2009 10:25:51AM, Jeff Squyres wrote:
> I was just trying to use () in an ini file and ran across an annoying 
> restriction: I had to make the whole thing be one long line:
>
> max_test_num = < ('open(IN, "./mpi_test_suite -l|") || die("cant open"); while () { 
> if (m/Num Tests : (\d+)/) { close(IN); return $1; } } close(IN); return 
> "0"; ')
> EOF
>
> Without that, the MTT parser would complain that it couldn't find the 
> closing ' quote (i.e., "('  ...  ')").  I tracked it down and it's 
> because if I did this:
>
> max_test_num = < ('
> open(IN, "./mpi_test_suite -l|") || die("cant open");
> while () {
> if (m/Num Tests : (\d+)/) { close(IN); return $1; }
> }
> close(IN);
> return "0";
> ')
> EOF
>
> then the parser stops looking for the closing quote on the "('" line 
> -- it doesn't go beyond the \n.  Yuck.

Ewww. I think the parser should be able to handle those newlines.

>
> Any suggestions?

When I need a multi-line (), I throw the perl code into a sub in
my funclet file. E.g., do this in a Cisco.pm file:

  sub max_test_num {
open(IN, "./mpi_test_suite -l|") || die("cant open");
while () {
if (m/Num Tests : (\d+)/) { 
  close(IN); 
  return $1; 
}
}
close(IN);
return "0";
  }

Put your funclet file next to your INI file, since your INI file will
now require your funclet file:

  foo/bar.ini
  funclets/Cisco.pm

And then have this in your INI file:

  [MTT]
  ...
  funclet_files = ("@INI_NAME@")/../funclets/Cisco.pm
  ...
  max_test_num = ::max_test_num()

-Ethan


>
> -- 
> Jeff Squyres
> Cisco Systems
>
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] [MTT svn] svn:mtt-svn r1306

[Ethan Mallove]

On Tue, Aug/11/2009 02:53:50PM, Mike Dubman wrote:
>Hey Jeff,
> 
>This code acts as a pre-processor during loading of ini file into mtt.
>It replaces builtin vars %VAR% with their values, for example:
> 
>...
>[Test run: trivial]
>my_sect_name=%INI_SECTION_NAME%
>...
> 
>%INI_SECTION_NAME% get replaced with real value. (trivial)
> 
>it is useful in the following situation:
> 
>...
>[test run: trivial]
>#param=_run_name()
>param=%INI_SECTION_NAME%
>...
> 
>when "param" was accessed from Reporter context, test_run_name() will
>return undef, but real value if %INI_SECTION_NAME% is used!

Doesn't _simple_section() do the same thing as
%INI_SECTION_NAME%? There are a couple predefined INI vars already,
but they use @VAR@ syntax:

  @INI_NAME@
  @PROGRAM_NAME@

The predefined vars are for strings that can't be known via the
Config::IniFiles module (e.g., the full path to the INI file and
client/mtt).

Could you add INI_SECTION_NAME to InsertINIPredefines, and use the
@VAR@ syntax?

-Ethan

> 
>regards
> 
>Mike
> 
>On Tue, Aug 11, 2009 at 2:03 PM, Jeff Squyres  wrote:
> 
>  Mike --
> 
>  Can you explain what this does?
> 
>  On Aug 11, 2009, at 4:28 AM,  wrote:
> 
>Author: miked
>Date: 2009-08-11 04:28:03 EDT (Tue, 11 Aug 2009)
>New Revision: 1306
>URL: https://svn.open-mpi.org/trac/mtt/changeset/1306
> 
>Log:
>added poor-man-inifile-preprocessor
>Text files modified:
>* trunk/client/mtt * * | * * 3 +++
>* trunk/lib/MTT/INI.pm | * *24 
>* 2 files changed, 27 insertions(+), 0 deletions(-)
> 
>Modified: trunk/client/mtt
>=
>=
>=
>=
>=
>=
>=
>=
>==
>--- trunk/client/mtt * *(original)
>+++ trunk/client/mtt * *2009-08-11 04:28:03 EDT (Tue, 11 Aug 2009)
>@@ -652,6 +652,9 @@
>* * * * # Expand all the "include_section" parameters
>* * * * $unfiltered = MTT::INI::ExpandIncludeSections($unfiltered);
> 
>+ * * * *# Expand all the "%PREDEFINED_VARS%" parameters
>+ * * * *$unfiltered = MTT::INI::ExpandPredefinedVars($unfiltered);
>+
>* * * * # Keep an unfiltered version of the ini file for error
>checking
>* * * * my $filtered = dclone($unfiltered);
> 
>Modified: trunk/lib/MTT/INI.pm
>
> ==
>--- trunk/lib/MTT/INI.pm * * * *(original)
>+++ trunk/lib/MTT/INI.pm * * * *2009-08-11 04:28:03 EDT (Tue, 11 Aug
>2009)
>@@ -275,6 +275,30 @@
>* * return $ini;
>*}
> 
>+sub ExpandPredefinedVars {
>+ * *my($ini) = @_;
>+
>+ * *foreach my $section ($ini->Sections) {
>+ * * * * * * * foreach my $parameter ($ini->Parameters($section)) {
>+ * * * * * * * * * * * my $val = $ini->val($section, $parameter);
>+ * * * * * * * * * * * if ( $val =~ /%INI_SECTION_NAME%/i ) {
>+ * * * * * * * * * * * * * * * my $sect = $section;
>+ * * * * * * * * * * * * * * * $sect =~ s/test run://gi;
>+ * * * * * * * * * * * * * * * $sect =~ s/test build://gi;
>+ * * * * * * * * * * * * * * * $sect =~ s/test get://gi;
>+ * * * * * * * * * * * * * * * $sect =~ s/mpi get://gi;
>+ * * * * * * * * * * * * * * * $sect =~ s/mpi install://gi;
>+ * * * * * * * * * * * * * * * $sect =~ s/mpi details://gi;
>+ * * * * * * * * * * * * * * * $sect =~ s/reporter://gi;
>+ * * * * * * * * * * * * * * * $val =~ s/%INI_SECTION_NAME%/$sect/g;
>+ * * * * * * * * * * * * * * * $ini->delval($section, $parameter);
>+ * * * * * * * * * * * * * * * $ini->newval($section, $parameter,
>$val);
>+ * * * * * * * * * * * }
>+ * * * * * * * }
>+ * *}
>+ * *return $ini;
>+}
>+
>*# Worker subroutine for recursive ExpandIncludeSections
>*sub _expand_include_sections {
>* * my($ini, $section) = @_;
>___
>mtt-svn mailing list
>mtt-...@open-mpi.org
>http://www.open-mpi.org/mailman/listinfo.cgi/mtt-svn
> 
>  --
>  Jeff Squyres
>  jsquy...@cisco.com
> 
>  ___
>  mtt-devel mailing list
>  mtt-de...@open-mpi.org
>  http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
> 
> References
> 
>Visible links
>. mailto:jsquy...@cisco.com
>. mailto:mi...@osl.iu.edu
>. https://svn.open-mpi.org/trac/mtt/changeset/1306
>. mailto:mtt-...@open-mpi.org
>. http://www.open-mpi.org/mailman/listinfo.cgi/mtt-svn
>. 

Re: [MTT devel] [MTT svn] svn:mtt-svn r1314

[Ethan Mallove]

Mike,

What if argv contains a funclet, e.g.,

  argv = ()

Won't this change prevent it from getting expanded?

-Ethan


On Tue, Sep/08/2009 09:43:37AM, mi...@osl.iu.edu wrote:
> Author: miked
> Date: 2009-09-08 09:43:37 EDT (Tue, 08 Sep 2009)
> New Revision: 1314
> URL: https://svn.open-mpi.org/trac/mtt/changeset/1314
> 
> Log:
> fix:
> 
> _np() can return incorrect value if used inside argv, here is a scenario:
> 
> This behavior can be explained in next words as evaluation _test()
> returns uninitialized $MTT::Test::Run::test_np that is initialized later in 
> _run_one_np function.
> 
> As a result using
> $MTT::Test::Run::test_argv = $run->{argv};
> allows to avoid damaging $MTT::Test::Run::test_argv  variable on current step 
> but evaluation of _np() is done with whole command_line.
> 
> 
> Text files modified: 
>trunk/lib/MTT/Test/RunEngine.pm | 2 +- 
>  
>1 files changed, 1 insertions(+), 1 deletions(-)
> 
> Modified: trunk/lib/MTT/Test/RunEngine.pm
> ==
> --- trunk/lib/MTT/Test/RunEngine.pm   (original)
> +++ trunk/lib/MTT/Test/RunEngine.pm   2009-09-08 09:43:37 EDT (Tue, 08 Sep 
> 2009)
> @@ -191,7 +191,7 @@
>  $MTT::Test::Run::test_executable_abspath = $test_exe_abs;
>  $MTT::Test::Run::test_executable_basename = $test_exe_basename;
>  
> -$MTT::Test::Run::test_argv = 
> MTT::Values::EvaluateString($run->{argv}, $ini, $test_run_full_name);
> +$MTT::Test::Run::test_argv = $run->{argv};
>  my $all_np = MTT::Values::EvaluateString($run->{np}, $ini, 
> $test_run_full_name);
>  
>  my $save_run_mpi_details = $MTT::Test::Run::mpi_details;
> ___
> mtt-svn mailing list
> mtt-...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-svn

Re: [MTT devel] [MTT svn] svn:mtt-svn r1314

[Ethan Mallove]

On Wed, Sep/09/2009 10:30:44AM, Mike Dubman wrote:
>Hey Eytan,
> 
>It seems argv is participating in the following scenarios:
> 
>1. argv should be defined in mtt.ini for every single [Test Run] section
>2. Currently, _argv() is returing un-evaluated argv`s value
>3. _argv() is usually part of "exec=" parameter line of [MPI
>Details], which is evaluated for very test invocation:
> 
>mpiexec @options@ -n _np() _executable() _argv()
> 
>According to analysis above, if argv contains funclets or variables, they
>will get expanded during "exec" line evaluation.

Okay, so we delay the evaluation of "argv" to when "exec" is
evaluated. The error case is:

  argv = _np()

Before fix:

  argv is undefined

After fix:

  argv is the value of _np()

-Ethan

> 
>regards
> 
>Mike
> 
>On Tue, Sep 8, 2009 at 9:10 PM, Ethan Mallove <ethan.mall...@sun.com>
>wrote:
> 
>  Mike,
> 
>  What if argv contains a funclet, e.g.,
> 
>  *argv = ()
> 
>  Won't this change prevent it from getting expanded?
> 
>  -Ethan
> 
>  On Tue, Sep/08/2009 09:43:37AM, mi...@osl.iu.edu wrote:
>  > Author: miked
>  > Date: 2009-09-08 09:43:37 EDT (Tue, 08 Sep 2009)
>  > New Revision: 1314
>  > URL: https://svn.open-mpi.org/trac/mtt/changeset/1314
>  >
>  > Log:
>  > fix:
>  >
>  > _np() can return incorrect value if used inside argv, here is a
>  scenario:
>  >
>  > This behavior can be explained in next words as evaluation _test()
>  > returns uninitialized $MTT::Test::Run::test_np that is initialized
>  later in _run_one_np function.
>  >
>  > As a result using
>  > $MTT::Test::Run::test_argv = $run->{argv};
>  > allows to avoid damaging $MTT::Test::Run::test_argv *variable on
>  current step but evaluation of _np() is done with whole
>  command_line.
>  >
>  >
>  > Text files modified:
>  > * *trunk/lib/MTT/Test/RunEngine.pm | * * 2 +-
>  > * *1 files changed, 1 insertions(+), 1 deletions(-)
>  >
>  > Modified: trunk/lib/MTT/Test/RunEngine.pm
>  >
>  
> ==
>  > --- trunk/lib/MTT/Test/RunEngine.pm * (original)
>  > +++ trunk/lib/MTT/Test/RunEngine.pm * 2009-09-08 09:43:37 EDT (Tue, 08
>  Sep 2009)
>  > @@ -191,7 +191,7 @@
>  > * * * * *$MTT::Test::Run::test_executable_abspath = $test_exe_abs;
>  > * * * * *$MTT::Test::Run::test_executable_basename =
>  $test_exe_basename;
>  >
>  > - * * * *$MTT::Test::Run::test_argv =
>  MTT::Values::EvaluateString($run->{argv}, $ini, $test_run_full_name);
>  > + * * * *$MTT::Test::Run::test_argv = $run->{argv};
>  > * * * * *my $all_np = MTT::Values::EvaluateString($run->{np}, $ini,
>  $test_run_full_name);
>  >
>  > * * * * *my $save_run_mpi_details = $MTT::Test::Run::mpi_details;
>  > ___
>  > mtt-svn mailing list
>  > mtt-...@open-mpi.org
>  > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-svn
>  ___
>  mtt-devel mailing list
>  mtt-de...@open-mpi.org
>  http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
> 
> References
> 
>Visible links
>. mailto:ethan.mall...@sun.com
>. mailto:mi...@osl.iu.edu
>. https://svn.open-mpi.org/trac/mtt/changeset/1314
>. mailto:mtt-...@open-mpi.org
>. http://www.open-mpi.org/mailman/listinfo.cgi/mtt-svn
>. mailto:mtt-de...@open-mpi.org
>. http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] [MTT svn] svn:mtt-svn r1319

[Ethan Mallove]

On Fri, Sep/25/2009 04:59:11PM, Jeff Squyres wrote:
> I'm not sure what you mean -- I thought they added a funclect, not a 
> field...?

I was commenting on both r1304 and r1319. 

These INI params:

  on_start
  on_stop

are very similar to these INI params: 

  after_each_exec
  before_any_exec
  after_all_exec

My thought was that it would make sense for them to use a similar
naming scheme and implementation (e.g., use suffix "_exec" and be
passed to DoCommand::Cmd()).

-Ethan

>
> On Sep 24, 2009, at 3:09 PM, Ethan Mallove wrote:
>
>> I think on_stop should conform more to these params:
>>
>>   after_each_exec
>>   before_any_exec
>>   after_all_exec
>>
>> E.g.,
>>
>>   before_mtt_start_exec
>>   after_mtt_start_exec
>>
>> Then have &_process_get_value_option() call DoCommand. Note, DoCommand
>> is aware of hashbangs (see &_contains_shell_script_characters()), so
>> _script() might be redundant.
>>
>> -Ethan
>>
>>
>> On Thu, Sep/24/2009 07:46:40PM, Mike Dubman wrote:
>> >Hey Jeff,
>> >
>> >On Thu, Sep 24, 2009 at 4:02 PM, Jeff Squyres <jsquy...@cisco.com> 
>> wrote:
>> >
>> >  The DoCommand.pm sub added ":\n" to the beginning to force the 
>> Bourne
>> >  shell interpreter. *This is necessary for some cases where an
>> >  interpreter is not otherwise specified.
>> >
>> >Im not familiar with :\n semantics, how does it force Bourne shell 
>> and
>> >what it actually does :)? (seems like leftovers from 1960)
>> >I think when interpreter is not explicitly specified - the default 
>> user`s
>> >shell is used.
>> >see in the DoCommand::Cmd() . it check the buffer`s* first line 
>> for
>> >#!/... semantic and if found - saves buffer to file, adds +x perm,* 
>> and
>> >just executes it as a regular script.
>> >
>> >When I passed a buffer with shell commands but 1st line was not 
>> #!/bin/sh
>> >- it* failed with syntax errors.
>> >
>> >*
>> >
>> >  I see why you did it -- you want the ability to add your own 
>> interpreter
>> >  in _script(). *Why not either make a parameter to add the 
>> ":\n" or
>> >  not, or better yet, have DoCommand.pm analyze the beginning of the
>> >  string and if it contains "^:\n" or "^#!", then don't add anything. 
>> *But
>> >  if it doesn't contain either of those, then prefix it with ":\n".*
>> >
>> >  How does that sound?
>> >
>> >sounds good!
>> >
>> >  Also, is "_script()" a good name? *If you can specify your 
>> own
>> >  interpreter, it might not be a shell script. *How about 
>> ()?
>> >
>> >ok - () it will be!
>> >*
>> >
>> >regards
>> >
>> >Mike
>> >
>> >  On Sep 24, 2009, at 8:06 AM, mi...@osl.iu.edu wrote:
>> >
>> >Author: miked
>> >Date: 2009-09-24 08:06:04 EDT (Thu, 24 Sep 2009)
>> >New Revision: 1319
>> >URL: https://svn.open-mpi.org/trac/mtt/changeset/1319
>> >
>> >Log:
>> >bug fix: CmdScript() - no need to add extra chars "\n:" to the 
>> start
>> >of shell script file
>> >new funclet: shell_script(section,param)
>> >
>> >Text files modified:
>> >*trunk/lib/MTT/DoCommand.pm * * * *| * * 2 +-
>> >*trunk/lib/MTT/Values/Functions.pm | * *19 +++
>> >*2 files changed, 20 insertions(+), 1 deletions(-)
>> >
>> >Modified: trunk/lib/MTT/DoCommand.pm
>> >
>> ==
>> >--- trunk/lib/MTT/DoCommand.pm *(original)
>> >+++ trunk/lib/MTT/DoCommand.pm *2009-09-24 08:06:04 EDT (Thu, 24 
>> Sep
>> >2009)
>> >@@ -797,7 +797,7 @@
>> >* *$cmds =~ s/\"$//
>> >* * * *if ($cmds =~ s/^\"//);
>> >
>> >- * *print $fh ":\n$cmds\n";
>> >+ * *print $fh "$cmds\n";
>> >* *close($fh);
>> >* *chmod(0700, $filename);
>> >
>> >Modified: trunk/lib/MTT/Values/Functions.pm
>> >
>> =

Re: [MTT devel] Analysis of hung jobs.

[Ethan Mallove]

On Tue, Oct/06/2009 10:23:48AM, Ashley Pittman wrote:
> 
> Further to the mail linked below, padb is able to perform diagnostics,
> including backtraces on hung jobs and integrates well into automated
> testing environments.

Can padb get a backtrace from a non-debuggable MPI (e.g., not compiled
with -g)?

-Ethan

> 
> The attached patch is a minimal change which should enable the
> functionality.  I don't however have access to a working MTT
> installation to test this however.
> 
> http://www.open-mpi.org/community/lists/mtt-devel/2009/06/0415.php
> 
> This will require a HEAD version of padb, at least r273 to allow it to
> accept the pid of mpirun rather than a jobid assigned by the underlying
> resource manager.
> 
> Yours,
> 
> Ashley,
> 
> -- 
> 
> Ashley Pittman, Bath, UK.
> 
> Padb - A parallel job inspection tool for cluster computing
> http://padb.pittman.org.uk

> Index: lib/MTT/DoCommand.pm
> ===
> --- lib/MTT/DoCommand.pm  (revision 1322)
> +++ lib/MTT/DoCommand.pm  (working copy)
> @@ -359,6 +359,7 @@
>  }
>  my $killed_status = undef;
>  my $last_over = 0;
> +my $padb_output;
>  while ($done > 0) {
>  my $nfound = select($rout = $rin, undef, undef, $t);
>  if (vec($rout, fileno(OUTread), 1) == 1) {
> @@ -410,6 +411,8 @@
>  my $timeout_email_recipient = 
> $MTT::Globals::Values->{docommand_timeout_notify_email};
>  my $timeout_notify_timeout  = 
> $MTT::Globals::Values->{docommand_timeout_notify_timeout};
>  
> + $padb_output = `padb --config-option rmgr=mpirun 
> --full-report=$pid`;
> +
>  if (defined($timeout_sentinel_file)) {
>  
>  # Email someone, if an email address has been specified
> @@ -493,6 +496,9 @@
>  # Return an anonymous hash containing the relevant data
>  
>  $ret->{result_stdout} = join('', @out);
> +if ( defined $padb_output ) {
> +  $ret->{result_stdout} .= "\n$padb_output";
> +}
>  $ret->{result_stderr} = join('', @err),
>  if (!$merge_output);
>  return $ret;

> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] Analysis of hung jobs.

[Ethan Mallove]

On Tue, Oct/06/2009 04:30:52PM, Ashley Pittman wrote:
> On Tue, 2009-10-06 at 11:25 -0400, Ethan Mallove wrote:
> > On Tue, Oct/06/2009 10:23:48AM, Ashley Pittman wrote:
> > > 
> > > Further to the mail linked below, padb is able to perform diagnostics,
> > > including backtraces on hung jobs and integrates well into automated
> > > testing environments.
> > 
> > Can padb get a backtrace from a non-debuggable MPI (e.g., not compiled
> > with -g)?
> 
> It's gets what is available from the application, without -g it will
> give you function names only, with -g it will also give you file names
> and line numbers and optionally variables, their types and values.
> 
> It can show the message queues regardless of the -g option.

I got the following error doing a simple test:

  $ padb --config-option rmgr=mpirun --full-report=12480
  Nested quantifiers in regex; marked by <-- HERE in m/\A# 
Start of str.
 "# Quote
 ((?:[^"\\]++ <-- HERE |\\.)*+) # Anyting which isn't \"
 "# Close quote
 ,?   # An optional comma.
 (.*) # Rest of line
 \z   # end.
 / at padb line 5044.

  $ perl --version
  This is perl, v5.8.4 built for sun4-solaris-64int

-Ethan

> 
> Ashley.
> 
> -- 
> 
> Ashley Pittman, Bath, UK.
> 
> Padb - A parallel job inspection tool for cluster computing
> http://padb.pittman.org.uk
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] Analysis of hung jobs.

[Ethan Mallove]

On Wed, Oct/07/2009 09:38:07PM, Ashley Pittman wrote:
> On Wed, 2009-10-07 at 16:21 -0400, Ethan Mallove wrote:
> 
> >   No secret file (/home/em162155/.padb-secret)
> >   Error: Could not load secret file on this node
> 
> You need to do this once to set a secret key for security purposes, run
> the following two commands and try again.
> 
> echo secret=ochi4aeZ > /home/em162155/.padb-secret
> chmod 0600 /home/em162155/.padb-secret

Getting closer ...

  $ padb --verbose --debug=all --config-option rmgr=mpirun --full-report=6336
  ...
  full job report for job 6336

  Attaching to job 6336
  mpirun resource manager requires pdsh to be installed
  Use of uninitialized value in printf at padb line 729.
  Use of uninitialized value in printf at padb line 729.
  DEBUG (verbose):   0: There are 0 processes over 0 hosts
  Fatal problem setting up the resource manager: mpirun

I assume it's referring to the below "pdsh"?

  http://sourceforge.net/projects/pdsh

-Ethan


> 
> Ashley,
> 
> -- 
> 
> Ashley Pittman, Bath, UK.
> 
> Padb - A parallel job inspection tool for cluster computing
> http://padb.pittman.org.uk
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] Analysis of hung jobs.

[Ethan Mallove]

On Thu, Oct/08/2009 03:18:07PM, Ashley Pittman wrote:
> On Thu, 2009-10-08 at 09:51 -0400, Ethan Mallove wrote:
> 
> > $ padb --verbose --debug=all --config-option rmgr=mpirun --full-report=6336
> >   ...
> >   full job report for job 6336
> > 
> >   Attaching to job 6336
> >   mpirun resource manager requires pdsh to be installed
> >   Use of uninitialized value in printf at padb line 729.
> >   Use of uninitialized value in printf at padb line 729.
> >   DEBUG (verbose):   0: There are 0 processes over 0 hosts
> >   Fatal problem setting up the resource manager: mpirun
> > 
> > I assume it's referring to the below "pdsh"?
> > 
> >   http://sourceforge.net/projects/pdsh
> 
> Yes, you'll need to able to ssh freely around from the node where
> padb/pdsh is running to all compute nodes as well.  For debian I had to
> add "export PDSH_RCMD_TYPE=ssh" to my .bashrc to tell it to use ssh
> rather than rsh.
> 
> Could you update to r283 as well, the "mpirun" resource manager is new
> and I discovered this morning that it didn't like digits in hostnames.
> As an added benefit it won't use pdsh or ssh if all processes are local.

It looks like it's using a bad option to pdsh?

  $ padb --debug=all --verbose --config-option rmgr=mpirun --full-report=24303
  ...
  padb version 3.n (Revision 283)
  full job report for job 24303

  Attaching to job 24303
  Use of uninitialized value in string ne at padb line 2720.
  Job has 1 process(es)
  Job spans 0 host(s)
  DEBUG (verbose):   0: There are 1 processes over 0 hosts
  DEBUG (verbose):   0: Remote process data available on frontend
  DEBUG (show_cmd):   0: pdsh -w  padb --inner --outer="burl-ct-v20z-0:52314"
  einner: pdsh: illegal option -- -
  einner: Usage: pdsh [-options] command ...
  einner: -Sreturn largest of remote command return values
  einner: -houtput usage menu and quit
  einner: -Voutput version information and quit
  einner: -qlist the option settings and quit
  einner: -bdisable ^C status feature (batch mode)
  einner: -denable extra debug information from ^C status
  einner: -l user   execute remote commands as user
  einner: -t secondsset connect timeout (default is 10 sec)
  einner: -u secondsset command timeout (no default)
  einner: -f n  use fanout of n nodes
  einner: -w host,host,...  set target node list on command line
  einner: -x host,host,...  set node exclusion list on command line
  einner: -R name   set rcmd module to name
  einner: -Ndisable hostname: labels on output lines
  einner: -Llist info on all loaded modules and exit
  einner: available rcmd modules: rsh,exec (default: rsh)
  Unexpected EOF from Inner stdout (connecting)
  Unexpected EOF from Inner stderr (connecting)
  Unexpected exit from parallel command (state=connecting)
  result from parallel command is 256 (state=connecting)
  Bad exit code from parallel command (exit_code=1)
  DEBUG (verbose):   5: Completed command

-Ethan

> 
> Ashley,
> 
> -- 
> Ashley Pittman, Bath, UK.
> 
> Padb - A parallel job inspection tool for cluster computing
> http://padb.pittman.org.uk
> 
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

[OMPI devel] GCC Linux trunk build errors in paffinity/hwloc

[Ethan Mallove]

IU and Oracle GCC/Linux nightly trunk builds are both dying on:

  ...
  Entering directory
  `.../openmpi-1.7a1r23202/opal/mca/paffinity/hwloc/hwloc/src'
CC traversal.lo
CC topology.lo
CC topology-synthetic.lo
CC bind.lo
CC cpuset.lo
CC misc.lo
CC topology-xml.lo
CC topology-linux.lo
CC topology-x86.lo
  topology-x86.c: In function 'look_proc':
  
.../openmpi-1.7a1r23202/opal/mca/paffinity/hwloc/hwloc/include/private/cpuid.h:54:
  error: can't find a register in class 'BREG' while reloading 'asm'
  
.../openmpi-1.7a1r23202/opal/mca/paffinity/hwloc/hwloc/include/private/cpuid.h:54:
  error: can't find a register in class 'BREG' while reloading 'asm'
  
.../openmpi-1.7a1r23202/opal/mca/paffinity/hwloc/hwloc/include/private/cpuid.h:54:
  error: can't find a register in class 'BREG' while reloading 'asm'
  
.../openmpi-1.7a1r23202/opal/mca/paffinity/hwloc/hwloc/include/private/cpuid.h:54:
  error: can't find a register in class 'BREG' while reloading 'asm'
  
.../openmpi-1.7a1r23202/opal/mca/paffinity/hwloc/hwloc/include/private/cpuid.h:54:
  error: can't find a register in class 'BREG' while reloading 'asm'
  
.../openmpi-1.7a1r23202/opal/mca/paffinity/hwloc/hwloc/include/private/cpuid.h:54:
  error: can't find a register in class 'BREG' while reloading 'asm'
  
.../openmpi-1.7a1r23202/opal/mca/paffinity/hwloc/hwloc/include/private/cpuid.h:54:
  error: can't find a register in class 'BREG' while reloading 'asm'
  
.../openmpi-1.7a1r23202/opal/mca/paffinity/hwloc/hwloc/include/private/cpuid.h:54:
  error: can't find a register in class 'BREG' while reloading 'asm'
  make[4]: *** [topology-x86.lo] Error 1

http://www.open-mpi.org/mtt/index.php?do_redir=1856

-Ethan

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r23665

[Ethan Mallove]

This fixes Libtool for an SVN checkout, but does not seem to get into
the nightly trunk tarball.  Why is that?

-Ethan

On Wed, Aug/25/2010 03:40:18PM, emall...@osl.iu.edu wrote:
> Author: emallove
> Date: 2010-08-25 15:40:17 EDT (Wed, 25 Aug 2010)
> New Revision: 23665
> URL: https://svn.open-mpi.org/trac/ompi/changeset/23665
> 
> Log:
> Patch `ltmain.sh` in `autogen.sh` per this Libtool thread:
> http://www.mail-archive.com/libtool@gnu.org/msg11249.html
> 
> Added:
>trunk/config/ltmain_pgi_tp.diff
> Text files modified: 
>trunk/autogen.sh | 8 
>1 files changed, 8 insertions(+), 0 deletions(-)
> 
> Modified: trunk/autogen.sh
> ==
> --- trunk/autogen.sh  (original)
> +++ trunk/autogen.sh  2010-08-25 15:40:17 EDT (Wed, 25 Aug 2010)
> @@ -11,6 +11,7 @@
>  # Copyright (c) 2004-2005 The Regents of the University of California.
>  # All rights reserved.
>  # Copyright (c) 2007-2010 Cisco Systems, Inc.  All rights reserved.
> +# Copyright (c) 2010  Oracle and/or its affiliates.  All rights reserved.
>  # $COPYRIGHT$
>  # 
>  # Additional copyrights may follow
> @@ -442,6 +443,13 @@
>  
>   echo "** Adjusting libltdl for OMPI :-("
>  
> +echo "   ++ patching PGI -tp bug in ltmain.sh"
> +if test -z "`grep -w tp config/ltmain.sh`"; then
> +patch -N -p0 < config/ltmain_pgi_tp.diff
> +else
> +echo "  -- your libtool doesn't need this! yay!"
> +fi
> +
>  echo "   ++ preopen error masking ib libltdl"
>  if test -r opal/libltdl/loaders/preopen.c; then
>  patch -N -p0 < config/libltdl-preopen-error.diff
> 
> Added: trunk/config/ltmain_pgi_tp.diff
> ==
> --- (empty file)
> +++ trunk/config/ltmain_pgi_tp.diff   2010-08-25 15:40:17 EDT (Wed, 25 Aug 
> 2010)
> @@ -0,0 +1,11 @@
> +--- config/ltmain.sh
>  config/ltmain.sh
> +@@ -4765,7 +4765,7 @@
> +   # -p, -pg, --coverage, -fprofile-* pass through profiling flag for GCC
> +   # @file GCC response files
> +   -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
> +-  -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*)
> ++  -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp|-tp=*)
> + func_quote_for_eval "$arg"
> +arg="$func_quote_for_eval_result"
> + func_append compile_command " $arg"
> ___
> svn-full mailing list
> svn-f...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/svn-full

Re: [OMPI devel] Autogen improvements: ready for blast off

[Ethan Mallove]

We can build an SVN checkout, but with a tarball we get this:

  ...
  Undefined first referenced
   symbol   in file
  opal_backtrace_print../../../opal/.libs/libopen-pal.so
  opal_backtrace_buffer   ../../../opal/.libs/libopen-pal.so
  ld: fatal: Symbol referencing errors. No output written to .libs/opal_wrapper

I suspect this is because the -G link lines for libopen-pal.so differ
between the tarball and the SVN checkout.  Specifically, this file
is *not* included in the link line in the tarball case:

  mca/backtrace/printstack/.libs/libmca_backtrace_printstack.a

I assume this means no backtrace plug-in is getting built in the
tarball case for some reason?

-Ethan

On Sat, Sep/18/2010 09:57:44AM, Jeff Squyres wrote:
> I made autogen.pl take care of removing stale generated-m4 files 
> automatically, so no one should need to manually rm any .m4 files.  Just 
> running autogen.pl should be sufficient.  Additionally, making nightly 
> tarballs was accidental collateral damage.  I'm working on fixing this; I 
> think I'm pretty close.
> 
> I updated the wiki pages last week with all you need to know about the 
> improvements to the build system:
> 
> https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen
> https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent
> https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework
> 
> If you make any new components or frameworks, I highly suggest you re-read 
> these pages.
> 
> A note from a prior email is critically important for all developers:
> 
> > 
> > *** THE MOST IMPORTANT THING DEVELOPERS NEED TO KNOW ***
> > 
> > 
> > 
> > If your component has a configure.m4 file, it MUST call AC_CONFIG_FILES 
> > for your Makefile.am!  (and/or any files that you want configure to 
> > generate).  We converted all existing configure.m4 files -- the 
> > ompi/mca/btl/tcp/configure.m4 is a nice simple example to see what I 
> > mean.
> > 
> > 
> > There's some other changes and improvements, but most of them are 
> > behind the scenes.  
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

[Ethan Mallove]

On Wed, Nov/19/2008 10:05:55AM, George Bosilca wrote:
> We're still using STL ? I was pretty much sure that we removed this 
> dependency a while ago ?

Open MPI is now set up to use either of Solaris's two versions of STL. The
problem is that if libtool links in libCrun/libCstd, then bad things happen if
the user code contains code for the other STL version. (Not sure if I got that
100% right.) Dan overhauled Open MPI's handling of STL a while ago (r17448,
r17418, r17409, ...). 

-Ethan


>
>   george.
>
> On Nov 19, 2008, at 09:11 , Ethan Mallove wrote:
>
>> 
>> WHAT: Add patch-libtool-for-sun-studio.pl script
>>
>> 
>> WHY:
>>
>> There are a couple issues with SunStudio and Libtool:
>>
>>1. The SunStudio libCrun/libCstd C++ libs get linked into Open MPI by
>>   libtool, which can lead to STL incompatibilities on Solaris
>>2. Libtool uses the wrong linker flags for C++ and Fortran (on Linux 
>> Sun
>>   Studio)
>>
>> Benefits of the fix:
>>
>>1. Anyone can easily build Open MPI using SunStudio
>>2. Nightly MTT Linux/SunStudio runs will pass
>>3. We can remove (most) of the Open MPI SunStudio building FAQ:
>>   http://www.open-mpi.org/faq/?category=building#build-sun-compilers
>>
>> 
>> WHERE: See attached patch; config/patch-libtool-for-sun-studio.pl and
>> configure.ac
>>
>> 
>> WHEN: Soon
>>
>> 
>> TIMEOUT: Later
>>
>> 
>>
>> One concern is that there's no precedent in Open MPI for patching libtool
>> *after* configure (we only patch libtool beforehand in autogen.sh). The
>> problem is that this particular libtool "patch" should only be used in the
>> case of Sun Studio which is not known until configure-time, and there does
>> not seem to be a generic patch that we could apply before configure.
>>
>> -Ethan
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

[Ethan Mallove]

On Wed, Nov/19/2008 05:12:03PM, Ralf Wildenhues wrote:
> Hello Ethan,
> 
> * Ethan Mallove wrote on Wed, Nov 19, 2008 at 04:11:23PM CET:
> > There are a couple issues with SunStudio and Libtool:
> 
> Which Libtool version are you using?  If not 2.2.2 or newer, then please
> retry with 2.2.6.  If the problem persists, then we should fix Libtool
> rather than patching OpenMPI.  That way, other packages benefit from the
> fix as well.
> 

I'm using 2.2 (for Solaris) and 2.1b (for Linux). I'll try
2.2.6.

Thanks,
Ethan


> Thanks,
> Ralf
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

[Ethan Mallove]

On Wed, Nov/19/2008 03:24:16PM, Ethan Mallove wrote:
> On Wed, Nov/19/2008 01:42:55PM, Ethan Mallove wrote:
> > On Wed, Nov/19/2008 05:12:03PM, Ralf Wildenhues wrote:
> > > Hello Ethan,
> > > 
> > > * Ethan Mallove wrote on Wed, Nov 19, 2008 at 04:11:23PM CET:
> > > > There are a couple issues with SunStudio and Libtool:
> > > 
> > > Which Libtool version are you using?  If not 2.2.2 or newer, then please
> > > retry with 2.2.6.  If the problem persists, then we should fix Libtool
> > > rather than patching OpenMPI.  That way, other packages benefit from the
> > > fix as well.
> > > 
> > 
> > I'm using 2.2 (for Solaris) and 2.1b (for Linux). I'll try
> > 2.2.6.
> > 
> 
> I'm seeing the same issue with the faulty "wl" Libtool
> variable in 2.2.6 with Linux SunStudio:
> 
>   ...
>   make[5]: Entering directory `ompi/mpi/f90'
>   /bin/sh ../../../libtool   --mode=link f90 -I../../../ompi/include 
> -I../../../ompi/include -M. -I. -I../../../ompi/mpi/f90  -m32 -xO5  
> -export-dynamic-o libmpi_f90.la -rpath /opt/SUNWhpc/HPC8.1/sun/lib mpi.lo 
> mpi_sizeof.lo mpi_comm_spawn_multiple_f90.lo mpi_testall_f90.lo 
> mpi_testsome_f90.lo mpi_waitall_f90.lo mpi_waitsome_f90.lo mpi_wtick_f90.lo 
> mpi_wtime_f90.lo   ../../../ompi/libmpi.la -lnsl -lutil  -lm
>   libtool: link: f90 -G  .libs/mpi.o .libs/mpi_sizeof.o 
> .libs/mpi_comm_spawn_multiple_f90.o .libs/mpi_testall_f90.o 
> .libs/mpi_testsome_f90.o .libs/mpi_waitall_f90.o .libs/mpi_waitsome_f90.o 
> .libs/mpi_wtick_f90.o .libs/mpi_wtime_f90.o   -Wl,-rpath -Wl,ompi/.libs 
> -Wl,-rpath 
> -Wl,/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs
>  -Wl,-rpath 
> -Wl,/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/opal/.libs
>  -Wl,-rpath -Wl,/opt/SUNWhpc/HPC8.1/sun/lib 
> -L/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs
>  
> -L/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/opal/.libs
>  ../../../ompi/.libs/libmpi.so 
> /tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs/libopen-rte.so
>  opal/.libs/libopen-pal.so -ldl -lnsl -lutil -lm  -m32   -mt -Wl,-soname 
> -Wl,libmpi_f90.so.0 -o .libs/libmpi_f90.so.0.0.0
>   f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored 
> otherwise
>   f90: Warning: Option -Wl,ompi/.libs passed to ld, if ld is invoked, ignored 
> otherwise
>   f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored 
> otherwise
>  f90: Warning: Option -Wl,orte/.libs passed to ld, if ld is invoked, 
> ignored otherwise
>  f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored 
> otherwise
>  f90: Warning: Option -Wl,opal/.libs passed to ld, if ld is invoked, 
> ignored otherwise
>  f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored 
> otherwise
>  f90: Warning: Option -Wl,/opt/SUNWhpc/HPC8.1/sun/lib passed to ld, if ld 
> is invoked, ignored otherwise
>  f90: Warning: Option -Wl,-soname passed to ld, if ld is invoked, ignored 
> otherwise
>  f90: Warning: Option -Wl,libmpi_f90.so.0 passed to ld, if ld is invoked, 
> ignored otherwise
>   /usr/bin/ld: unrecognized option '-Wl,-rpath'
>  /usr/bin/ld: use the --help option for usage information
>   make[5]: *** [libmpi_f90.la] Error 1
>  make[5]: Leaving directory `ompi/mpi/f90'
>   make[4]: *** [install-recursive] Error 1
>   make[4]: Leaving directory `ompi/mpi/f90'
>   make[3]: *** [install] Error 2
>  make[3]: Leaving directory `ompi/mpi/f90'
>   make[2]: *** [install-recursive] Error 1
>   make[2]: Leaving directory `ompi'
>   make[1]: *** [install] Error 2
>   make[1]: Leaving directory `ompi'
>   make: *** [install-recursive] Error 1
> 
> The wl var in auto-generated libtool script should be set to
> "".

I think I found a potential problem. I see this in configure:

case `$CC -V 2>&1 | sed 5q` in
*Sun\ C*)
  # Sun C 5.9
  lt_prog_compiler_pic='-KPIC'
  lt_prog_compiler_static='-Bstatic'
  lt_prog_compiler_wl='-Wl,'
  ;;
*Sun\ F*)
  # Sun Fortran 8.3 passes all unrecognized flags to the linker
  lt_prog_compiler_pic='-KPIC'
  lt_prog_compiler_static='-Bstatic'
  lt_prog_compiler_wl=''
  ;;
esac
;;

The above appears to be looking for a Fortran version string from the
C compiler, but it wouldn't match our version string anyway:

  $ f90 -V
  f90: Sun Ceres Fortran 95 8.3 SunOS_sparc 2008/01/28

The result is that lt_prog_compiler_wl never g

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

[Ethan Mallove]

On Fri, Nov/21/2008 01:02:12PM, Ralf Wildenhues wrote:
> Hello Ethan, all,
> 
> * Ethan Mallove wrote on Thu, Nov 20, 2008 at 10:33:08PM CET:
> > On Thu, Nov/20/2008 07:00:31PM, Ralf Wildenhues wrote:
> > > 
> > > Ah, ok.  Please try the patch below instead of yours, thanks.
> > 
> > Your patch seems to work, though I get this:
> > 
> >libtool: Version mismatch error.  This is libtool 2.2.7a, but the
> >libtool: definition of this LT_INIT comes from libtool 2.2.6.
> >libtool: You should recreate aclocal.m4 with macros from libtool 2.2.7a
> >libtool: and run autoconf again.
> > 
> > I take it the above error will occur if I have two different libtools
> > in my PATH?
> 
> No.  That means the macro files that were picked up were from Libtool
> 2.2.6, while the ltmain.sh file is from 2.2.7a.
> 
> > This comment could be a little misleading because the same is true for
> > Sun Fortran 8.1 and 8.2:
> > 
> >   # Sun Fortran 8.3 passes all unrecognized flags to the linker
> 
> OK.  I think we simply didn't have any other version to test at the time
> this was written.  We usually list the version somewhere so we can check
> for version-specific issues, should they later show up.
> 
> I will update the comment to list '8.1 through 8.3', when I commit your
> patch (sometime this weekend); thanks for testing it.
> 
> > I don't know of a version of Sun Fortran that accepts -Wl the way GNU
> > Fortran does. I will let you know if I find one.
> 
> Thanks.
> 
> > > > I'm still running into the Cstd/stlport4 issue with 2.2.6. That is,
> > > > this line appears in the libtool script:
> > > > 
> > > >   postdeps="-library=Cstd -library=Crun"
> > >
> > > Do you have the string " -library=stlport4 " in $CXX $CXXFLAGS?
> > > If not, then how can Libtool detect that you use stlport?
> > 
> > Ok. When I use -library=stlport4, I get libstlport linked to
> > libmpi_cxx, instead of libCstd. Doesn't that then lock the user into
> > having to use stlport4 when we want them to be able to use either Cstd
> > or stlport4?
> 
> Hmm, yes, it does.  It is a bit of a problem to let libtool avoid either
> standard C++ library in general: with shared libraries or even
> dlopen'able modules, this can result in undefined symbols at run time.
> 
> As the code is currently written in libtool.m4, there is an undocumented
> way which you can use to get the effects of adding neither library: set
> solaris_use_stlport4=yes.  You can use this, either as argument to
> configure, or set it inside configure.ac (or a macro) so that it is
> expanded before AC_PROG_LIBTOOL.
> 
> However, as it is undocumented, there is no guarantee that it will
> continue to work indefinitely.  What Libtool should instead do future is
> provide some configure flag to allow to specify that no C++ standard
> library is to be linked in by default.  That would help for a couple of
> different setups with other compilers as well.  IMHO OpenMPI can use
> the solaris_use_stlport4=yes until such a functionality is in place.

Nice. This workaround works. I don't suppose there's a similar
workaround to unset "wl" in the FC libtool section? If not, I think we
still need the heinous post-configure workaround script. Otherwise,
since there won't be a stable Libtool that contains the Sun Fortran
fix for a while, I propose the attached patch.

Thanks,
Ethan


> 
> Cheers, and thanks,
> Ralf
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
Index: configure.ac
===
--- configure.ac(revision 19845)
+++ configure.ac(working copy)
@@ -1071,6 +1076,12 @@

 ompi_show_subtitle "Libtool configuration"

+# Use the undocumented solaris_use_stlport4 libtool variable to turn off any
+# Cstd/stlport4 linkage. This allows Open MPI to be C++ STL agnostic.
+if test "x$ompi_cv_c_compiler_vendor" = "xsun"; then
+solaris_use_stlport4="yes"
+fi
+
 dnl Not all versions of LT set the PACKAGE_VERSION
 m4_ifdef([LT_PACKAGE_VERSION], [], [m4_define([LT_PACKAGE_VERSION], [1.5.22])])

@@ -1356,3 +1367,10 @@
 test/datatype/Makefile
 ])
 AC_OUTPUT
+
+# Fix libtool script bug that passes -Wl to f90, which Sun f90 does not 
understand.
+# (This can be removed if using Libtool 2.2.7 or higher)
+ompi_patch_libtool_for_sun_studio="config/patch-libtool-for-sun-studio.pl"
+if test "x$ompi_cv_c_compiler_vendor" = "xsun" -a -x 
"$ompi_patch_libtool_for_sun_studio"; then
+   

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

[Ethan Mallove]

On Sun, Nov/23/2008 09:19:12AM, Ralf Wildenhues wrote:
> * Ethan Mallove wrote on Fri, Nov 21, 2008 at 09:01:56PM CET:
> > On Fri, Nov/21/2008 01:02:12PM, Ralf Wildenhues wrote:
> > > IMHO OpenMPI can use
> > > the solaris_use_stlport4=yes until such a functionality is in place.
> > 
> > Nice. This workaround works. I don't suppose there's a similar
> > workaround to unset "wl" in the FC libtool section? If not, I think we
> > still need the heinous post-configure workaround script. Otherwise,
> > since there won't be a stable Libtool that contains the Sun Fortran
> > fix for a while, I propose the attached patch.
> 
> While I suppose your patch works, I think in similar situations, OpenMPI
> has resorted to patching input files to configure (like aclocal.m4 or
> ltmain.sh).  Search autogen.sh for instances of 'patch'.
> 

I think I got it. I patch libtool.m4 in autogen.sh after libtoolize
creates libtool.m4. How is the patch now?

-Ethan


> (This is merely an observation; I am not an OpenMPI developer.)
> 
> Cheers,
> Ralf
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
Index: configure.ac
===
--- configure.ac(revision 19845)
+++ configure.ac(working copy)
@@ -1071,6 +1076,12 @@

 ompi_show_subtitle "Libtool configuration"

+# Use the undocumented solaris_use_stlport4 libtool variable to turn off any
+# Cstd/stlport4 linkage. This allows Open MPI to be C++ STL agnostic.
+if test "x$ompi_cv_c_compiler_vendor" = "xsun"; then
+solaris_use_stlport4="yes"
+fi
+
 dnl Not all versions of LT set the PACKAGE_VERSION
 m4_ifdef([LT_PACKAGE_VERSION], [], [m4_define([LT_PACKAGE_VERSION], [1.5.22])])

Index: autogen.sh
===
--- autogen.sh  (revision 19845)
+++ autogen.sh  (working copy)
@@ -541,6 +541,12 @@
 aclocal.m4 > aclocal.m4.new
 cp aclocal.m4.new aclocal.m4
 rm -f aclocal.m4.new
+
+# This patch fixes a bug in Libtool's detection of the Sun Studio
+# Fortran compiler. See the below e-mail thread for more details:
+#   http://www.open-mpi.org/community/lists/devel/2008/11/4920.php
+echo "   ++ patching for Sun Studio Fortran compilers"
+patch -N -p0 < config/lt-sun-fortran.diff > /dev/null 2>&1
 fi

 run_and_check $ompi_autoconf
Index: config/lt-sun-fortran.diff
===
--- config/lt-sun-fortran.diff  (revision 0)
+++ config/lt-sun-fortran.diff  (revision 0)
@@ -0,0 +1,26 @@
+--- config/libtool.m4.orig
 config/libtool.m4
+@@ -3947,17 +3947,17 @@ m4_if([$1], [CXX], [
+   ;;
+   *)
+   case `$CC -V 2>&1 | sed 5q` in
+-  *Sun\ C*)
+-# Sun C 5.9
++  *Sun\ F* | *Sun*Fortran*)
++# Sun Fortran 8.3 passes all unrecognized flags to the linker
+ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+ _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+-_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++_LT_TAGVAR(lt_prog_compiler_wl, $1)=''
+ ;;
+-  *Sun\ F*)
+-# Sun Fortran 8.3 passes all unrecognized flags to the linker
++  *Sun\ C*)
++# Sun C 5.9
+ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+ _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+-_LT_TAGVAR(lt_prog_compiler_wl, $1)=''
++_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+ ;;
+   esac
+   ;;

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r20003 (Solaris malloc.h issue)

[Ethan Mallove]

Hi Patrick,

r20003 seems to break MX support on Solaris.

  $ cd ompi/mca/common/mx
  $ make
  ...
  "/usr/include/malloc.h", line 46: syntax error before or at: (
  "/usr/include/malloc.h", line 47: syntax error before or at: (
  "/usr/include/malloc.h", line 48: syntax error before or at: (
  "/usr/include/malloc.h", line 48: cannot have void object: size_t
  "/usr/include/malloc.h", line 48: identifier redeclared: size_t
  ... <4000 more lines of compiler errors> ...

The below patch makes it so opal/util/malloc.h is used instead of
/usr/include/malloc.h and the compiler errors go away. (I also needed
to include errno.h.) Would this be okay to do?

  diff -r 347f52a3713f ompi/mca/common/mx/common_mx.c
  --- ompi/mca/common/mx/common_mx.c
  +++ ompi/mca/common/mx/common_mx.c
  @@ -23,9 +23,8 @@
   #include "ompi/constants.h"
   #include "common_mx.h"

  -#ifdef HAVE_MALLOC_H
  -#include 
  -#endif
  +#include 
  +#include "opal/util/malloc.h"
   #include "opal/memoryhooks/memory.h"
   #include "opal/mca/base/mca_base_param.h"
   #include "ompi/runtime/params.h"

I tested the above on Solaris and Linux with SunStudio.

Regards,
Ethan


On Fri, Nov/14/2008 11:17:59PM, patr...@osl.iu.edu wrote:
> Author: patrick
> Date: 2008-11-14 23:17:58 EST (Fri, 14 Nov 2008)
> New Revision: 20003
> URL: https://svn.open-mpi.org/trac/ompi/changeset/20003
> 
> Log:
> Define a "fake" mpool to provide a memory release callback for the 
> memory hooks (munmap) and initialize the mallopt component, and 
> nothing else.
> Use this mpool in the MX common initialization, supporting both BTL 
> and MTL. Automatically set the MX_RCACHE environment variable to 
> enable registration cache in MX.
> 
> Tested with success for munmap() and large free().
> 
> 
> Added:
>trunk/ompi/mca/mpool/fake/
>trunk/ompi/mca/mpool/fake/Makefile.am
>trunk/ompi/mca/mpool/fake/configure.params
>trunk/ompi/mca/mpool/fake/mpool_fake.h
>trunk/ompi/mca/mpool/fake/mpool_fake_component.c
>trunk/ompi/mca/mpool/fake/mpool_fake_module.c
> Text files modified: 
>trunk/ompi/mca/common/mx/common_mx.c |56 
> +++ 
>1 files changed, 55 insertions(+), 1 deletions(-)
> 
> Modified: trunk/ompi/mca/common/mx/common_mx.c
> ==
> --- trunk/ompi/mca/common/mx/common_mx.c  (original)
> +++ trunk/ompi/mca/common/mx/common_mx.c  2008-11-14 23:17:58 EST (Fri, 
> 14 Nov 2008)
> @@ -9,6 +9,8 @@
>   * University of Stuttgart.  All rights reserved.
>   * Copyright (c) 2004-2006 The Regents of the University of California.
>   * All rights reserved.
> + * Copyright (c) 2008  Myricom. All rights reserved.
> + * 
>   * $COPYRIGHT$
>   *
>   * Additional copyrights may follow
> @@ -21,11 +23,29 @@
>  #include "ompi/constants.h"
>  #include "common_mx.h"
>  
> +#ifdef HAVE_MALLOC_H
> +#include 
> +#endif
> +#include "opal/memoryhooks/memory.h"
> +#include "opal/mca/base/mca_base_param.h"
> +#include "ompi/runtime/params.h"
> +#include "ompi/mca/mpool/mpool.h"
> +#include "ompi/mca/mpool/base/base.h"
> +#include "ompi/mca/mpool/fake/mpool_fake.h"
> +
> +
> +int mx__regcache_clean(void *ptr, size_t size);
> +
>  static int ompi_common_mx_initialize_ref_cnt = 0;
> +static mca_mpool_base_module_t *ompi_common_mx_fake_mpool = 0;
> +
>  int
>  ompi_common_mx_initialize(void)
>  {
>  mx_return_t mx_return;
> +struct mca_mpool_base_resources_t mpool_resources;
> +int index, value;
> +
>  ompi_common_mx_initialize_ref_cnt++;
>  
>  if(ompi_common_mx_initialize_ref_cnt == 1) { 
> @@ -35,7 +55,37 @@
>   * library does not exit the application.
>   */
>  mx_set_error_handler(MX_ERRORS_RETURN);
> -
> + 
> + /* If we have a memory manager available, and
> +mpi_leave_pinned == -1, then set mpi_leave_pinned to 1.
> +
> +We have a memory manager if:
> +- we have both FREE and MUNMAP support
> +- we have MUNMAP support and the linux mallopt */
> + value = opal_mem_hooks_support_level();
> + if (((value & (OPAL_MEMORY_FREE_SUPPORT | OPAL_MEMORY_MUNMAP_SUPPORT))
> +  == (OPAL_MEMORY_FREE_SUPPORT | OPAL_MEMORY_MUNMAP_SUPPORT))
> + || ((value & OPAL_MEMORY_MUNMAP_SUPPORT) &&
> + OMPI_MPOOL_BASE_HAVE_LINUX_MALLOPT)) {
> +   index = mca_base_param_find("mpi", NULL, "leave_pinned");
> +   if (index >= 0)
> +if ((mca_base_param_lookup_int(index, ) == OPAL_SUCCESS) 
> + && (value == -1)) {
> +   
> +   ompi_mpi_leave_pinned = 1;
> +   setenv("MX_RCACHE", "2", 1);
> +   mpool_resources.regcache_clean = mx__regcache_clean;
> +   ompi_common_mx_fake_mpool = 
> + mca_mpool_base_module_create("fake", NULL, _resources);
> +   if (!ompi_common_mx_fake_mpool) {
> + 

Re: [OMPI devel] 1.3.1 -- bad MTT from Cisco

[Ethan Mallove]

On Wed, Mar/11/2009 11:38:19AM, Jeff Squyres wrote:
> As Terry stated, I think this bugger is quite rare.  I'm having a helluva 
> time trying to reproduce it manually (over 5k runs this morning and still 
> no segv).  Ugh.

5k of which test(s)? Can this error happen on any test? I am wondering
if we could narrow down to a smaller subset of the nightly tests to
reproduce this (the way Terry did by looping over the same test(s) for
a looong time). I see the following over the past 30 days:

  # | Date range  | Org   | Hostname  | Platform name  | 
Hardware | OS| MPI name  | MPI version| Suite| Test 
  | np | Stdout   | Pass | Fail | Skip | Timed | Perf
  1 | 2009-02-12 06:47:56 | sun   | burl-ct-v440-2| burl-ct-v440-2 | sun4u  
  | SunOS | ompi-nightly-v1.3 | 1.3.1a0r20508  | ibm-64   | cxx_create_disp 
   | 8  | btl_sm_add_procs | 0| 1| 0| 0 | 0
  2 | 2009-02-27 23:37:02 | sun   | burl-ct-v20z-2| burl-ct-v20z-2 | i86pc  
  | SunOS | ompi-nightly-v1.3 | 1.3.1rc1r20628 | ibm-64   | lbub
   | 4  | btl_sm_add_procs | 0| 1| 0| 0 | 0
  3 | 2009-03-05 00:15:39 | sun   | burl-ct-v20z-2| burl-ct-v20z-2 | i86pc  
  | SunOS | ompi-nightly-v1.3 | 1.3.1rc3r20684 | ibm-32   | loop
   | 4  | btl_sm_add_procs | 0| 1| 0| 0 | 0
  4 | 2009-03-05 22:31:43 | sun   | burl-ct-v20z-2| burl-ct-v20z-2 | i86pc  
  | SunOS | ompi-nightly-v1.3 | 1.3.1rc4r20704 | intel-64 | 
MPI_Type_size_MPI_LB_UB_c  | 4  | btl_sm_add_procs | 0| 1| 0| 0 
| 0
  5 | 2009-03-10 14:47:36 | cisco | svbu-mpi[035-036] | svbu-mpi   | x86_64 
  | Linux | ompi-nightly-v1.3 | 1.3.1rc5r20730 | intel| 
MPI_Test_cancelled_false_c | 8  | btl_sm_add_procs | 0| 1| 0| 0 
| 0

What do these tests have in common?

  ./intel_tests/src/MPI_Test_cancelled_false_c.c
  ./intel_tests/src/MPI_Type_size_MPI_LB_UB_c.c
  ./ibm/onesided/cxx_create_disp.cc
  ./ibm/datatype/lbub2.c
  ./ibm/datatype/loop.c
  ./ibm/datatype/lbub.c

It almost looks like the problem is more likely to occur if MPI_UB or
MPI_LB is involved or am I just imagining things?

-Ethan

>
> Looking through the sm startup code, I can't see exactly what the problem 
> would be.  :-(
>
>
> On Mar 11, 2009, at 11:34 AM, Ralph Castain wrote:
>
>> I'll run some tests with 1.3.1 on one of our systems and see if it
>> shows up there. If it is truly rare and was in 1.3.0, then I
>> personally don't have a problem with it. Got bigger problems with
>> hanging collectives, frankly - and we don't know how the sm changes
>> will affect this problem, if at all.
>>
>>
>> On Mar 11, 2009, at 7:50 AM, Terry Dontje wrote:
>>
>> > Jeff Squyres wrote:
>> >> So -- Brad/George -- this technically isn't a regression against
>> >> v1.3.0 (do we know if this can happen in 1.2?  I don't recall
>> >> seeing it there, but if it's so elusive...  I haven't been MTT
>> >> testing the 1.2 series in a long time).  But it is a nonzero problem.
>> >>
>> > I have not seen 1.2 fail with this problem but I honestly don't know
>> > if that is a fluke or not.
>> >
>> > --td
>> >
>> >> Should we release 1.3.1 without a fix?
>> >>
>> >
>> >>
>> >> On Mar 11, 2009, at 7:30 AM, Ralph Castain wrote:
>> >>
>> >>> I actually wasn't implying that Eugene's changes -caused- the
>> >>> problem,
>> >>> but rather that I thought they might have -fixed- the problem.
>> >>>
>> >>> :-)
>> >>>
>> >>>
>> >>> On Mar 11, 2009, at 4:34 AM, Terry Dontje wrote:
>> >>>
>> >>> > I forgot to mention that since I ran into this issue so long ago I
>> >>> > really doubt that Eugene's SM changes has caused this issue.
>> >>> >
>> >>> > --td
>> >>> >
>> >>> > Terry Dontje wrote:
>> >>> >> Hey!!!  I ran into this problem many months ago but its been so
>> >>> >> elusive that I've haven't nailed it down.  First time we saw this
>> >>> >> was last October.  I did some MTT gleaning and could not find
>> >>> >> anyone but Solaris having this issue under MTT.  What's
>> >>> interesting
>> >>> >> is I gleaned Sun's MTT results and could not find any of these
>> >>> >> failures as far back as last October.
>> >>> >> What it looked like to me was that the shared memory segment
>> >>> might
>> >>> >> not have been initialized with 0's thus allowing one of the
>> >>> >> processes to start accessing addresses that did not have an
>> >>> >> appropriate address.  However, when I was looking at this I was
>> >>> >> told the mmap file was created with ftruncate which essentially
>> >>> >> should 0 fill the memory.  So I was at a loss as to why this was
>> >>> >> happening.
>> >>> >>
>> >>> >> I was able to reproduce this for a little while manually
>> >>> setting up
>> >>> >> a script that ran and small np=2 program over and over for
>> >>> sometime
>> >>> >> under 3-4 days.  But around November I was unable to reproduce
>> >>> the
>> >>> >> issue after 4 days of runs and threw up my 

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r20003 (Solaris malloc.h issue)

[Ethan Mallove]

Hi,

I think I have a better fix for this issue. It is to simply #include
 *before* ompi_config.h.

  --- ompi/mca/common/mx/common_mx.c
  +++ ompi/mca/common/mx/common_mx.c
  @@ -19,15 +19,16 @@
* $HEADER$
*/

  +#ifdef HAVE_MALLOC_H
  +#include 
  +#endif
  +
   #include "ompi_config.h"
   #include "orte/util/show_help.h"
   #include "ompi/constants.h"
   #include "common_mx.h"

   #include 
  -#ifdef HAVE_MALLOC_H
  -#include 
  -#endif
   #include "opal/memoryhooks/memory.h"
   #include "opal/mca/base/mca_base_param.h"
   #include "ompi/runtime/params.h"

The reason for doing this is because ompi_config.h (which includes
ompi_config_bottom.h) #defines "malloc", so we end up with OMPI code
getting spliced into the Solaris /usr/include/malloc.h code. 

Is this fix okay?

-Ethan

On Wed, Dec/10/2008 04:29:31PM, Ethan Mallove wrote:
> Hi Patrick,
> 
> r20003 seems to break MX support on Solaris.
> 
>   $ cd ompi/mca/common/mx
>   $ make
>   ...
>   "/usr/include/malloc.h", line 46: syntax error before or at: (
>   "/usr/include/malloc.h", line 47: syntax error before or at: (
>   "/usr/include/malloc.h", line 48: syntax error before or at: (
>   "/usr/include/malloc.h", line 48: cannot have void object: size_t
>   "/usr/include/malloc.h", line 48: identifier redeclared: size_t
>   ... <4000 more lines of compiler errors> ...
> 
> The below patch makes it so opal/util/malloc.h is used instead of
> /usr/include/malloc.h and the compiler errors go away. (I also needed
> to include errno.h.) Would this be okay to do?
> 
>   diff -r 347f52a3713f ompi/mca/common/mx/common_mx.c
>   --- ompi/mca/common/mx/common_mx.c
>   +++ ompi/mca/common/mx/common_mx.c
>   @@ -23,9 +23,8 @@
>#include "ompi/constants.h"
>#include "common_mx.h"
>
>   -#ifdef HAVE_MALLOC_H
>   -#include 
>   -#endif
>   +#include 
>   +#include "opal/util/malloc.h"
>#include "opal/memoryhooks/memory.h"
>#include "opal/mca/base/mca_base_param.h"
>#include "ompi/runtime/params.h"
> 
> I tested the above on Solaris and Linux with SunStudio.
> 
> Regards,
> Ethan
> 
> 
> On Fri, Nov/14/2008 11:17:59PM, patr...@osl.iu.edu wrote:
> > Author: patrick
> > Date: 2008-11-14 23:17:58 EST (Fri, 14 Nov 2008)
> > New Revision: 20003
> > URL: https://svn.open-mpi.org/trac/ompi/changeset/20003
> > 
> > Log:
> > Define a "fake" mpool to provide a memory release callback for the 
> > memory hooks (munmap) and initialize the mallopt component, and 
> > nothing else.
> > Use this mpool in the MX common initialization, supporting both BTL 
> > and MTL. Automatically set the MX_RCACHE environment variable to 
> > enable registration cache in MX.
> > 
> > Tested with success for munmap() and large free().
> > 
> > 
> > Added:
> >trunk/ompi/mca/mpool/fake/
> >trunk/ompi/mca/mpool/fake/Makefile.am
> >trunk/ompi/mca/mpool/fake/configure.params
> >trunk/ompi/mca/mpool/fake/mpool_fake.h
> >trunk/ompi/mca/mpool/fake/mpool_fake_component.c
> >trunk/ompi/mca/mpool/fake/mpool_fake_module.c
> > Text files modified: 
> >trunk/ompi/mca/common/mx/common_mx.c |56 
> > +++ 
> >1 files changed, 55 insertions(+), 1 deletions(-)
> > 
> > Modified: trunk/ompi/mca/common/mx/common_mx.c
> > ==
> > --- trunk/ompi/mca/common/mx/common_mx.c(original)
> > +++ trunk/ompi/mca/common/mx/common_mx.c2008-11-14 23:17:58 EST (Fri, 
> > 14 Nov 2008)
> > @@ -9,6 +9,8 @@
> >   * University of Stuttgart.  All rights reserved.
> >   * Copyright (c) 2004-2006 The Regents of the University of California.
> >   * All rights reserved.
> > + * Copyright (c) 2008  Myricom. All rights reserved.
> > + * 
> >   * $COPYRIGHT$
> >   *
> >   * Additional copyrights may follow
> > @@ -21,11 +23,29 @@
> >  #include "ompi/constants.h"
> >  #include "common_mx.h"
> >  
> > +#ifdef HAVE_MALLOC_H
> > +#include 
> > +#endif
> > +#include "opal/memoryhooks/memory.h"
> > +#include "opal/mca/base/mca_base_param.h"
> > +#include "ompi/runtime/params.h"
> > +#include "ompi/mca/mpool/mpool.h"
> > +#include "ompi/mca/mpool/base/base.h"
> > +#include "ompi/mca/mpo

Re: [OMPI devel] [OMPI svn] svn:open-mpi r22014

[Ethan Mallove]

On Fri, Sep/25/2009 09:31:51PM, Ralph Castain wrote:
> I think there is a problem with this change - here is a warning I get when 
> compiling on Mac and Linux:
>
> ompi_debuggers.c:265: warning: no previous prototype for ?MPIR_Breakpoint?
>
> Can you please take a look?

Can you send me your config.log file? I can't reproduce the warning
using GCC (3.4.6) on RHEL 4.

-Ethan

>
> Thanks
> Ralph
>
> On Sep 25, 2009, at 1:14 PM, emall...@osl.iu.edu wrote:
>
>> Author: emallove
>> Date: 2009-09-25 15:14:19 EDT (Fri, 25 Sep 2009)
>> New Revision: 22014
>> URL: https://svn.open-mpi.org/trac/ompi/changeset/22014
>>
>> Log:
>> Remove `static` from `MPIR_Breakpoint` so Intel compilers will not inline 
>> it
>>
>> Text files modified:
>>   trunk/ompi/debuggers/ompi_debuggers.c | 2 +-
>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> Modified: trunk/ompi/debuggers/ompi_debuggers.c
>> ==
>> --- trunk/ompi/debuggers/ompi_debuggers.c(original)
>> +++ trunk/ompi/debuggers/ompi_debuggers.c2009-09-25 15:14:19 EDT (Fri, 
>> 25 
>> Sep 2009)
>> @@ -261,7 +261,7 @@
>>  * defined in orterun for the starter.  It should never conflict with
>>  * this one, but we'll make it static, just to be sure.
>>  */
>> -static void *MPIR_Breakpoint(void)
>> +void *MPIR_Breakpoint(void)
>> {
>> return NULL;
>> }
>> ___
>> svn mailing list
>> s...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/svn
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] [OMPI svn] svn:open-mpi r22014

[Ethan Mallove]

On Mon, Sep/28/2009 02:05:14PM, Jeff Squyres wrote:
> Try a newer compiler than gcc 3.4 -- it's pretty ancient.

I don't get the warning with 4.1.2 either.

-Ethan

>
>
> On Sep 28, 2009, at 2:03 PM, Ethan Mallove wrote:
>
>> On Fri, Sep/25/2009 09:31:51PM, Ralph Castain wrote:
>> > I think there is a problem with this change - here is a warning I get 
>> when
>> > compiling on Mac and Linux:
>> >
>> > ompi_debuggers.c:265: warning: no previous prototype for 
>> ?MPIR_Breakpoint?
>> >
>> > Can you please take a look?
>>
>> Can you send me your config.log file? I can't reproduce the warning
>> using GCC (3.4.6) on RHEL 4.
>>
>> -Ethan
>>
>> >
>> > Thanks
>> > Ralph
>> >
>> > On Sep 25, 2009, at 1:14 PM, emall...@osl.iu.edu wrote:
>> >
>> >> Author: emallove
>> >> Date: 2009-09-25 15:14:19 EDT (Fri, 25 Sep 2009)
>> >> New Revision: 22014
>> >> URL: https://svn.open-mpi.org/trac/ompi/changeset/22014
>> >>
>> >> Log:
>> >> Remove `static` from `MPIR_Breakpoint` so Intel compilers will not 
>> inline
>> >> it
>> >>
>> >> Text files modified:
>> >>   trunk/ompi/debuggers/ompi_debuggers.c | 2 +-
>> >>   1 files changed, 1 insertions(+), 1 deletions(-)
>> >>
>> >> Modified: trunk/ompi/debuggers/ompi_debuggers.c
>> >> 
>> ==
>> >> --- trunk/ompi/debuggers/ompi_debuggers.c(original)
>> >> +++ trunk/ompi/debuggers/ompi_debuggers.c2009-09-25 15:14:19 EDT 
>> (Fri, 25
>> >> Sep 2009)
>> >> @@ -261,7 +261,7 @@
>> >>  * defined in orterun for the starter.  It should never conflict with
>> >>  * this one, but we'll make it static, just to be sure.
>> >>  */
>> >> -static void *MPIR_Breakpoint(void)
>> >> +void *MPIR_Breakpoint(void)
>> >> {
>> >> return NULL;
>> >> }
>> >> ___
>> >> svn mailing list
>> >> s...@open-mpi.org
>> >> http://www.open-mpi.org/mailman/listinfo.cgi/svn
>> >
>> >
>> > ___
>> > devel mailing list
>> > de...@open-mpi.org
>> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>> 
>
>
> -- 
> Jeff Squyres
> jsquy...@cisco.com
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] [OMPI svn] svn:open-mpi r22014

[Ethan Mallove]

On Mon, Sep/28/2009 03:11:46PM, Ethan Mallove wrote:
> On Mon, Sep/28/2009 02:05:14PM, Jeff Squyres wrote:
> > Try a newer compiler than gcc 3.4 -- it's pretty ancient.
> 
> I don't get the warning with 4.1.2 either.

To get the warning I needed to enable some developer configure options (e.g.,
mkdir .svn && configure). 

The below patch gets rid of the warning, but is it the right way?

--- ompi/debuggers/debuggers.h
+++ ompi/debuggers/debuggers.h
@@ -40,6 +40,11 @@
  */
 OMPI_DECLSPEC void ompi_debugger_notify_abort(char *string);

+/**
+ * Breakpoint function for parallel debuggers.
+ */
+OMPI_DECLSPEC void *MPIR_Breakpoint(void);
+
 END_C_DECLS

 #endif /* OMPI_DEBUGGERS_H */

-Ethan


> 
> -Ethan
> 
> >
> >
> > On Sep 28, 2009, at 2:03 PM, Ethan Mallove wrote:
> >
> >> On Fri, Sep/25/2009 09:31:51PM, Ralph Castain wrote:
> >> > I think there is a problem with this change - here is a warning I get 
> >> when
> >> > compiling on Mac and Linux:
> >> >
> >> > ompi_debuggers.c:265: warning: no previous prototype for 
> >> ?MPIR_Breakpoint?
> >> >
> >> > Can you please take a look?
> >>
> >> Can you send me your config.log file? I can't reproduce the warning
> >> using GCC (3.4.6) on RHEL 4.
> >>
> >> -Ethan
> >>
> >> >
> >> > Thanks
> >> > Ralph
> >> >
> >> > On Sep 25, 2009, at 1:14 PM, emall...@osl.iu.edu wrote:
> >> >
> >> >> Author: emallove
> >> >> Date: 2009-09-25 15:14:19 EDT (Fri, 25 Sep 2009)
> >> >> New Revision: 22014
> >> >> URL: https://svn.open-mpi.org/trac/ompi/changeset/22014
> >> >>
> >> >> Log:
> >> >> Remove `static` from `MPIR_Breakpoint` so Intel compilers will not 
> >> inline
> >> >> it
> >> >>
> >> >> Text files modified:
> >> >>   trunk/ompi/debuggers/ompi_debuggers.c | 2 +-
> >> >>   1 files changed, 1 insertions(+), 1 deletions(-)
> >> >>
> >> >> Modified: trunk/ompi/debuggers/ompi_debuggers.c
> >> >> 
> >> ==
> >> >> --- trunk/ompi/debuggers/ompi_debuggers.c(original)
> >> >> +++ trunk/ompi/debuggers/ompi_debuggers.c2009-09-25 15:14:19 EDT 
> >> (Fri, 25
> >> >> Sep 2009)
> >> >> @@ -261,7 +261,7 @@
> >> >>  * defined in orterun for the starter.  It should never conflict with
> >> >>  * this one, but we'll make it static, just to be sure.
> >> >>  */
> >> >> -static void *MPIR_Breakpoint(void)
> >> >> +void *MPIR_Breakpoint(void)
> >> >> {
> >> >> return NULL;
> >> >> }
> >> >> ___
> >> >> svn mailing list
> >> >> s...@open-mpi.org
> >> >> http://www.open-mpi.org/mailman/listinfo.cgi/svn
> >> >
> >> >
> >> > ___
> >> > devel mailing list
> >> > de...@open-mpi.org
> >> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >>
> >> 
> >
> >
> > -- 
> > Jeff Squyres
> > jsquy...@cisco.com
> >
> >
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r22077

[Ethan Mallove]

I think we're missing a couple semicolons (see below).

On Thu, Oct/08/2009 01:53:43PM, r...@osl.iu.edu wrote:
> Author: rhc
> Date: 2009-10-08 13:53:43 EDT (Thu, 08 Oct 2009)
> New Revision: 22077
> URL: https://svn.open-mpi.org/trac/ompi/changeset/22077
> 
> Log:
> Closes #2048: Fix uninitialized variable in MPI_Comm_spawn_multiple
> 
> Submitted by tdd, reviewed by jsquyres, RM-approved by bbenton
> 
> Includes r22075 and r22076
> 
> 
> Properties modified: 
>branches/v1.3/   (props changed)
> Text files modified: 
>branches/v1.3/ompi/mpi/c/comm_spawn.c  | 5 +   
> 
>branches/v1.3/ompi/mpi/c/comm_spawn_multiple.c | 7 ++- 
> 
>2 files changed, 11 insertions(+), 1 deletions(-)
> 
> Modified: branches/v1.3/ompi/mpi/c/comm_spawn.c
> ==
> --- branches/v1.3/ompi/mpi/c/comm_spawn.c (original)
> +++ branches/v1.3/ompi/mpi/c/comm_spawn.c 2009-10-08 13:53:43 EDT (Thu, 
> 08 Oct 2009)
> @@ -10,6 +10,7 @@
>   * Copyright (c) 2004-2005 The Regents of the University of California.
>   * All rights reserved.
>   * Copyright (c) 2006-2007 Cisco Systems, Inc.  All rights reserved.
> + * Copyright (c) 2009  Sun Microsystems, Inc.  All rights reserved.
>   * $COPYRIGHT$
>   * 
>   * Additional copyrights may follow
> @@ -106,6 +107,10 @@
>  if (OMPI_SUCCESS != (rc = ompi_dpm.open_port (port_name, 
> OMPI_RML_TAG_INVALID))) {
>  goto error;
>  }
> +} else if (1 < ompi_comm_size(comm)) {
> + /* we do not support non_mpi spawns on comms this size */
> + rc = OMPI_ERR_NOT_SUPPORTED

Here.

> + goto error;
>  }
>  if (OMPI_SUCCESS != (rc = ompi_dpm.spawn (1, , , 
> , 
>, port_name))) {
> 
> Modified: branches/v1.3/ompi/mpi/c/comm_spawn_multiple.c
> ==
> --- branches/v1.3/ompi/mpi/c/comm_spawn_multiple.c(original)
> +++ branches/v1.3/ompi/mpi/c/comm_spawn_multiple.c2009-10-08 13:53:43 EDT 
> (Thu, 08 Oct 2009)
> @@ -10,6 +10,7 @@
>   * Copyright (c) 2004-2005 The Regents of the University of California.
>   * All rights reserved.
>   * Copyright (c) 2006  Cisco Systems, Inc.  All rights reserved.
> + * Copyright (c) 2009  Sun Microsystems, Inc.  All rights reserved.
>   * $COPYRIGHT$
>   * 
>   * Additional copyrights may follow
> @@ -45,7 +46,7 @@
>  ompi_communicator_t *newcomp=NULL;
>  bool send_first=false; /* they are contacting us first */
>  char port_name[MPI_MAX_PORT_NAME];
> -bool non_mpi, cumulative = false;
> +bool non_mpi = false, cumulative = false;
>  
>  MEMCHECKER(
>  memchecker_comm(comm);
> @@ -146,6 +147,10 @@
>  if (OMPI_SUCCESS != (rc = ompi_dpm.open_port (port_name, 
> OMPI_RML_TAG_INVALID))) {
>  goto error;
>  }
> +} else if (1 < ompi_comm_size(comm)) {
> + /* we do not support non_mpi spawns on comms this size */
> + rc = OMPI_ERR_NOT_SUPPORTED

And here.

-Ethan

> + goto error;
>  }
>  if (OMPI_SUCCESS != (rc = ompi_dpm.spawn(count, array_of_commands,
>   array_of_argv, 
> array_of_maxprocs,
> ___
> svn-full mailing list
> svn-f...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/svn-full

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r22663

[Ethan Mallove]

About this change - I have been seeing the below error while trying to
build the trunk recently:

  $ make ...
  cd . && /bin/bash /tmp/config-missing-bug-in-trunk/trunk/config/missing --run 
aclocal-1.10 -I config
  configure.ac:939: warning: OMPI_CONFIGURE_SETUP is m4_require'd but not 
m4_defun'd
  config/ompi_mca.m4:37: OMPI_MCA is expanded from...
  configure.ac:939: the top level
   cd . && /bin/bash /tmp/config-missing-bug-in-trunk/trunk/config/missing 
--run automake-1.10 --foreign
  configure.ac:939: warning: OMPI_CONFIGURE_SETUP is m4_require'd but not 
m4_defun'd
  ...
  ompi/mca/allocator/Makefile.am:31: WANT_INSTALL_HEADERS does not appear in 
AM_CONDITIONAL
  ... repeats 49 times ...
  make: *** [configure] Error 1

While fixing ACLOCAL_AMFLAGS gets the build to complete successfully,
the real issue is: why is config/missing getting immediately invoked
by "make"?  This wasn't happening before, and it means configure is
getting run twice per build now.

Any ideas what could be causing this?

-Ethan


On Thu, Feb/18/2010 01:11:23PM, emall...@osl.iu.edu wrote:
> Author: emallove
> Date: 2010-02-18 13:11:23 EST (Thu, 18 Feb 2010)
> New Revision: 22663
> URL: https://svn.open-mpi.org/trac/ompi/changeset/22663
> 
> Log:
> In case `config/missing` gets invoked, ensure that all the OMPI-specific m4
> macros are defined.
> 
> Text files modified: 
>trunk/Makefile.am | 2 +-  
>1 files changed, 1 insertions(+), 1 deletions(-)
> 
> Modified: trunk/Makefile.am
> ==
> --- trunk/Makefile.am (original)
> +++ trunk/Makefile.am 2010-02-18 13:11:23 EST (Thu, 18 Feb 2010)
> @@ -25,4 +25,4 @@
>  dist-hook:
>   csh "$(top_srcdir)/config/distscript.csh" "$(top_srcdir)" "$(distdir)" 
> "$(OMPI_VERSION)" "$(OMPI_SVN_R)"
>  
> -ACLOCAL_AMFLAGS = -I config
> +ACLOCAL_AMFLAGS = -I config -I opal/config -I ompi/config -I orte/config
> ___
> svn-full mailing list
> svn-f...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/svn-full

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r22663

[Ethan Mallove]

On Thu, Feb/18/2010 01:16:33PM, Jeff Squyres wrote:
> On Feb 18, 2010, at 1:12 PM, Ethan Mallove wrote:
> 
> > About this change - I have been seeing the below error while trying to
> > build the trunk recently:
> > 
> >   $ make ...
> >   cd . && /bin/bash /tmp/config-missing-bug-in-trunk/trunk/config/missing 
> > --run aclocal-1.10 -I config
> >   configure.ac:939: warning: OMPI_CONFIGURE_SETUP is m4_require'd but not 
> > m4_defun'd
> >   config/ompi_mca.m4:37: OMPI_MCA is expanded from...
> >   configure.ac:939: the top level
> >cd . && /bin/bash /tmp/config-missing-bug-in-trunk/trunk/config/missing 
> > --run automake-1.10 --foreign
> >   configure.ac:939: warning: OMPI_CONFIGURE_SETUP is m4_require'd but not 
> > m4_defun'd
> >   ...
> > 
> > While fixing ACLOCAL_AMFLAGS gets the build to complete successfully,
> > the real issue is: why is config/missing getting immediately invoked
> > by "make"?  This wasn't happening before, and it means configure is
> > getting run twice per build now.
> > 
> > Any ideas what could be causing this?
> 
> No -- it should not be happening.  I'd think that those extra -I's shouldn't 
> be necessary.
> 
> Check the usual suspects, such as time synchronization between NFS client and 
> server, etc.
>
> You might also want to run "make -d" to see what rules are being invoked and 
> why.

make -d shows the problem:

  ...
  Prerequisite `config/libtool.m4' is newer than target `aclocal.m4'.
  ...
  Must remake target `aclocal.m4'.
  ...

This occurs because autogen.sh patches aclocal.m4 before patching
libtool.m4.  I don't know why we're suddenly seeing this now, but this
vile hack fixes it:

Index: autogen.sh
===
--- autogen.sh
+++ autogen.sh
@@ -594,6 +594,9 @@
 rm -f libtool.m4.rej
 fi

+# Ensure libtool.m4 is very old so that make does not rebuild aclocal.m4
+touch -t 19700101.00 config/libtool.m4
+
 run_and_check $ompi_autoconf

 run_and_check $ompi_automake --foreign -a --copy --include-deps

-Ethan

> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> 
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r16909 (f77_hello compiler error)

[Ethan Mallove]

Hello,

Is this change (or r16908) causing the below error in the MTT
trivial test (f77_hello)? The error occurs on Solaris and
Linux.

  ...
  NOTICE: Invoking /ws/ompi-tools/SUNWspro/SOS11/bin/f90 -f77 -ftrap=%none 
-I/installs/cGmK/install/include/v9 -xarch=amd64 hello.f -o f77_hello 
-R/installs/cGmK/install/lib/amd64 -R/opt/mx/lib 
-L/installs/cGmK/install/lib/amd64 -lmpi_f77 -lmpi -lopen-rte 
-lopen-pal -lsocket -lnsl -lrt -lm
  hello.f:
   MAIN main:
  Undefined first referenced
   symbol   in file
  intercept_extra_state_t_class   
/installs/cGmK/install/lib/amd64/libmpi_f77.so
  ld: fatal: Symbol referencing errors. No output written to f77_hello

See also http://www.open-mpi.org/mtt/index.php?do_redir=475.

Didn't look that closely here, just noted the line change
involving "intercept_extra_state".

-Ethan


On Sun, Dec/09/2007 07:19:59PM, bosi...@osl.iu.edu wrote:
> Author: bosilca
> Date: 2007-12-09 19:19:58 EST (Sun, 09 Dec 2007)
> New Revision: 16909
> URL: https://svn.open-mpi.org/trac/ompi/changeset/16909
> 
> Log:
> Avoid a compiler warning about the function being defined but not
> used when we compile the profiling layer.
> 
> Text files modified: 
>trunk/ompi/mpi/f77/register_datarep_f.c | 6 +++--- 
>  
>1 files changed, 3 insertions(+), 3 deletions(-)
> 
> Modified: trunk/ompi/mpi/f77/register_datarep_f.c
> ==
> --- trunk/ompi/mpi/f77/register_datarep_f.c   (original)
> +++ trunk/ompi/mpi/f77/register_datarep_f.c   2007-12-09 19:19:58 EST (Sun, 
> 09 Dec 2007)
> @@ -90,6 +90,9 @@
>  MPI_Aint *extra_state_f77;
>  } intercept_extra_state_t;
>  
> +OBJ_CLASS_DECLARATION(intercept_extra_state_t);
> +
> +#if !OMPI_PROFILE_LAYER
>  static void intercept_extra_state_constructor(intercept_extra_state_t *obj)
>  {
>  obj->read_fn_f77 = NULL;
> @@ -98,9 +101,6 @@
>  obj->extra_state_f77 = NULL;
>  }
>  
> -OBJ_CLASS_DECLARATION(intercept_extra_state_t);
> -
> -#if !OMPI_PROFILE_LAYER
>  OBJ_CLASS_INSTANCE(intercept_extra_state_t,
> opal_list_item_t,
> intercept_extra_state_constructor, NULL);
> ___
> svn-full mailing list
> svn-f...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/svn-full

Re: [OMPI devel] inline asm patch

[Ethan Mallove]

On Thu, Dec/20/2007 08:50:41AM, Jeff Squyres wrote:
> After Ethan's inline assembly patch (to make the
> upper-level atomic.h declarations match the lower-level
> inline definitions -- if they exist), I've had a problem
> with the PGI compiler on Linux.
>
> I finally tracked down the issue this morning -- it seems
> that OMPI_GCC_INLINE_ASSEMBLY is 0 for the PGI compiler.
> Hence, none of the assembly routines are inlined.  The
> logic for the lower layer to say "these functions aren't
> inlined" didn't take the value of OMPI_GCC_INLINE_ASSEMBLY
> into account, so the upper layer was still prefixing the
> declarations with "static inline", which led to linker
> problems later.
>
> The below patch fixes the problem for me, but I wanted to
> run it by others before committing because it's fairly
> tangled logic (both inline for easy reading and attached
> in case my mail client munges the formatting).


Can this logic be up-leveled into sys/atomic.h (see below)
such that we have it in one atomic.h file instead of nine
atomic.h files? This would mean that if a given lower-level
/atomic.h file defines a non-GCC-style inline atomic,
that file would have to set an OPAL_HAVE_INLINE_* macro, but
I don't see any cases like this currently (there is only
XLC-style inline assembly in powerpc/atomic.h).


Index: opal/include/opal/sys/atomic.h
===
--- opal/include/opal/sys/atomic.h  (revision 17003)
+++ opal/include/opal/sys/atomic.h  (working copy)
@@ -111,19 +111,27 @@

 /**
  *
- * Zero these macros in the architecture-specific atomic.h files if we
- * need to define their corresponding functions as non-inline (e.g.,
- * in an opal/asm/base/.asm file). These macros allow us to make
- * the signatures of the prototype and definition identical.
- * 
+ * Set or unset these macros in the architecture-specific atomic.h
+ * files if we need to specify them as inline or non-inline 
+ *
  */
+#if !OMPI_GCC_INLINE_ASSEMBLY
+#define OPAL_HAVE_INLINE_ATOMIC_MEM_BARRIER 0
+#define OPAL_HAVE_INLINE_ATOMIC_CMPSET_32 0
+#define OPAL_HAVE_INLINE_ATOMIC_ADD_32 0
+#define OPAL_HAVE_INLINE_ATOMIC_SUB_32 0
+#define OPAL_HAVE_INLINE_ATOMIC_CMPSET_64 0
+#define OPAL_HAVE_INLINE_ATOMIC_ADD_64 0
+#define OPAL_HAVE_INLINE_ATOMIC_SUB_64 0
+#else
 #define OPAL_HAVE_INLINE_ATOMIC_MEM_BARRIER 1
 #define OPAL_HAVE_INLINE_ATOMIC_CMPSET_32 1
-#define OPAL_HAVE_INLINE_ATOMIC_CMPSET_64 1
 #define OPAL_HAVE_INLINE_ATOMIC_ADD_32 1
 #define OPAL_HAVE_INLINE_ATOMIC_SUB_32 1
+#define OPAL_HAVE_INLINE_ATOMIC_CMPSET_64 1
 #define OPAL_HAVE_INLINE_ATOMIC_ADD_64 1
 #define OPAL_HAVE_INLINE_ATOMIC_SUB_64 1
+#endif

 /**
  *

-Ethan

>
> -- 
> Jeff Squyres
> Cisco Systems
>
> Index: opal/include/opal/sys/ia32/atomic.h
> ===
> --- opal/include/opal/sys/ia32/atomic.h   (revision 16997)
> +++ opal/include/opal/sys/ia32/atomic.h   (working copy)
> @@ -10,6 +10,7 @@
>   * Copyright (c) 2004-2005 The Regents of the University of California.
>   * All rights reserved.
>   * Copyright (c) 2007  Sun Microsystems, Inc.  All rights reserverd.
> + * Copyright (c) 2007  Cisco Systems, Inc.  All rights reserverd.
>   * $COPYRIGHT$
>   *
>   * Additional copyrights may follow
> @@ -51,6 +52,21 @@
>  #undef OPAL_HAVE_INLINE_ATOMIC_CMPSET_64
>  #define OPAL_HAVE_INLINE_ATOMIC_CMPSET_64 0
>
> +/* If we don't have GCC inline assembly, then nothing is inline */
> +#if !OMPI_GCC_INLINE_ASSEMBLY
> +#undef OPAL_HAVE_INLINE_ATOMIC_MEM_BARRIER
> +#define OPAL_HAVE_INLINE_ATOMIC_MEM_BARRIER 0
> +
> +#undef OPAL_HAVE_INLINE_ATOMIC_CMPSET_32
> +#define OPAL_HAVE_INLINE_ATOMIC_CMPSET_32 0
> +
> +#undef OPAL_HAVE_INLINE_ATOMIC_ADD_32
> +#define OPAL_HAVE_INLINE_ATOMIC_ADD_32 0
> +
> +#undef OPAL_HAVE_INLINE_ATOMIC_SUB_32
> +#define OPAL_HAVE_INLINE_ATOMIC_SUB_32 0
> +#endif
> +
>  /**
>   *
>   * Memory Barriers
> Index: opal/include/opal/sys/amd64/atomic.h
> ===
> --- opal/include/opal/sys/amd64/atomic.h  (revision 16997)
> +++ opal/include/opal/sys/amd64/atomic.h  (working copy)
> @@ -10,6 +10,7 @@
>   * Copyright (c) 2004-2005 The Regents of the University of California.
>   * All rights reserved.
>   * Copyright (c) 2007  Sun Microsystems, Inc.  All rights reserverd.
> + * Copyright (c) 2007  Cisco Systems, Inc.  All rights reserverd.
>   * $COPYRIGHT$
>   *
>   * Additional copyrights may follow
> @@ -44,7 +45,18 @@
>
>  #define OPAL_HAVE_ATOMIC_CMPSET_64 1
>
> +/* If we don't have GCC inline assembly, then nothing is inline */
> +#if