George and I talked about this on the phone; I understand his questions better now.
Nathan and I will get together and work through his questions and come back to everyone with some answers / proposals. On Jul 19, 2013, at 9:27 AM, George Bosilca <bosi...@icl.utk.edu> wrote: > > 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 > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
