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/
