I think I miss the discussion about these AMCA here at UTK and about
the benefits that give us. Anyway, I have some comments about this
You seems to add the new AMCA files into the same string as the
default MCA param file and then you call your new function
fixup_files. This function take a directory as an argument, and you
will try to match everything with the path coming from an MCA
parameter described as AMCA specific. Doesn't really make sense to
me ! If the prefix is AMCA specific then don't match the MCA param
files with it, if not then correct the help message.
Last thing about this patch. Having the opal MCA layer export a bool
variable just to make sure the life of orted and orterun (which in
fact don't really need it as it set it multiple times to true ???) is
much easier, isn't something that look to me like a good approach.
In fact, I was wondering what is the real difference between having
this new AMCA stuff and extending the mca_param_files default MCA
On Mar 1, 2007, at 8:52 AM, Josh Hursey wrote:
> I just committed back to the trunk the Aggregate MCA (AMCA) Parameter
> Set work that Jeff Squyres and I have been working on. This will be a
> part of the eventual v1.3 release.
> The motivation for creating AMCA parameter sets came from the
> realization that for certain applications a large number of MCA
> parameters needed to be set for the job to run well and/or as the
> user expects. So the goal of this work was to help reduce the number
> of MCA parameters that the user has to manage, therefore leading to a
> better end user experience with Open MPI.
> AMCA parameter set files are formated exactly like the "~/.openmpi/
> mca-params.conf" configuration files. In addition when AMCA parameter
> sets are used the user may still override the parameters on the
> command line if they like.
> For example, let's say there is a set of MCA parameters that a user
> would need to set to get good performance out of Netpipe when using
> Open IB. They would typically run the application as:
> shell$ mpirun -np 2 NPmpi
> To use the AMCA parameter set for Open IB the user would run:
> shell$ mpirun -np 2 -am btl-openib-benchmark NPmpi
> This will load a series of MCA parameters for the user. If they
> wanted to override the max_btls MCA parameter for tuning reasons they
> would run:
> shell$ mpirun -np 2 -am btl-openib-benchmark -mca
> btl_open_ib_max_btls 10 NPmpi
> AMCA parameter sets can be coupled. If we take the example above and
> wanted to also use an AMCA parameter set for TCP, the user would run:
> shell$ mpirun -np 2 -am btl-openib-benchmark:btl-tcp-benchmark -
> mca btl_open_ib_max_btls 10 NPmpi
> The AMCA parameter sets are loaded in priority order. This means that
> the OpenIB AMCA set has priority over the TCP AMCA set. So if the TCP
> AMCA sets the MCA parameter "mpi_leave_pinned=0" and the OpenIB AMCA
> sets it to "mpi_leave_pinned=1" then the latter, OpenIB version, will
> be used.
> Additional Related MCA parameters:
> - mca_base_param_file_prefix
> (Default: NULL)
> This is the fullname of the "-am" mpirun option. Used to
> specify a ':' separated list of AMCA parameter set files.
> - mca_base_param_file_path
> (Default: $SYSCONFDIR/amca-param-sets/:$CWD)
> The path to search for AMCA files with relative paths. A
> warning will be printed if the AMCA file cannot be found.
> If you have any problems with this new feature let me know. There
> will be an FAQ coming shortly about this I suspect.
> Josh Hursey
> Josh Hursey
> devel mailing list
"Half of what I say is meaningless; but I say it so that the other
half may reach you"