My point is the following. I favor consistent behaviors and I'm always in favor of respecting the configuration files. ALWAYS like in the word that mean all cases without exception. Thus, by default, ompi_info as any other component of the Open MPI infrastructure MUST read the configuration files and respect all options provided there. And here was another inconsistency on the "new" approach. ompi_info reports some of the values (like the eager size and friends), while deciding to ignore others (like the list of the active PML and BTL).
I do concede that there are cases where we need something slightly different, maybe as a convenience. If there is a need for a special case for ompi_info to ignore the configuration files, let's add it. But do't make it the default, instead request a special command line argument for it. There were several mentions about he MPI_T in this discussion. If I understand what was said about it, all components are loaded, they register their parameters and them based on user selection some the them are unloaded. Thus my question is: from the tools perspective what is the interest of knowing that a special MPI_T parameter exists but not be able to use it (because the originator component was meanwhile unloaded)? George. On Jul 18, 2013, at 18:12 , "Jeff Squyres (jsquyres)" <jsquy...@cisco.com> wrote: > On Jul 18, 2013, at 11:50 AM, George Bosilca <bosi...@icl.utk.edu> wrote: > >> How is this part of the code validated? It might capitalize on some type of >> "trust". Unfortunately … I have no such notion. > > Not sure what you're asking here. > >> I would rather take the path of the "least astonishment", a __consistent__ >> behavior where we always abide to the configuration files (user level as >> well as system level). If you want to see every single parameter possibly >> available to you (based on your rights of course), temporary remove the >> configuration file. Or we can provide a specific ompi_info option to ignore >> the configuration files, but not make this the default. > > > I think MPI applications and ompi_info are different cases. > > 1. We've definitely had cases of user (and OMPI developer!) confusion over > the years where people would run ompi_info and not see their favorite MCA > component listed. After a while, they figured out it was because they had an > env variable/file limiting which components were used (e.g., > OMPI_MCA_btl=sm,tcp,self would silently disable all other BTLs in ompi_info > output). This actually seems to be fairly counter-intuitive behavior, if you > ask me -- it was done this way as an artifact of the old implementation > architecture. > > Personally, I think changing ompi_info's behavior to always listing all > components is a good idea. Is there a reason to be concerned about the > memory footprint and IO traffic of running ompi_info? > > What might be a useful addition, however, is in the above example (user has > OMPI_MCA_btl=sm,tcp,self in their environment) to somehow mark all other BTL > params as "inactive because of OMPI_MCA_BTL env variable value", or something > like that. > > *** If someone wants this behavior, please propose a specific way to mark > prettyprint and parsable ompi_info output. > > 2. MPI application behavior has not changed -- if you call MPI_Init, we open > exactly the same frameworks/components that were opened before. But if > you're using a tool (i.e., call the MPI_T init function), then you pay an > extra price (potentially more dlopens, more memory usage, etc.). This is the > same as it has always been for tools: tools cost something (memory, > performance, whatever). > > That being said, if you want a different behavior, please propose something > specific (e.g., specific new MCA param + value(s) for specific behavior(s)). > > -- > 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
