Re: [OMPI devel] MCA component open
(moving to devel list for wider audience) Hmm. I thought the UTK stuff from a while ago supposedly changed this behavior to only open the components that were specifically requested. This behavior looks like the *original* MCA behavior -- open them all, then discard what we don't want (but doesn't necessarily reclaim the memory because of how dlclose works). On May 2, 2008, at 9:48 AM, Ralph Castain wrote: Yo guys I've noticed something on the trunk that just doesn't strike me as correct. If I specify "-mca plm rsh", it is my expectation that (a) only the rsh component will be opened, and (b) only the rsh module will be selected, unless that component indicates that it cannot run. What I am seeing, though, is that -all- the plm components are being opened. This is not only unnecessary, but consumes memory and leads to concern over whether or not some other module could become active. Is this the intended behavior? If so, may I suggest we change it in Josh's branch prior to bringing it over? Ralph -- Jeff Squyres Cisco Systems
[OMPI devel] cpc openib stuff
Was merged into the trunk early this morning. OOB/XOOB is still the default. Let me know if anyone sees any problems. -- Jeff Squyres Cisco Systems
Re: [OMPI devel] MCA component open
Well, I have a current version of the trunk. I add an MCA param to the environment indicating that only rsh is to be used by the orted. Yet I get an output from every orted indicating that slurm (misspelled!) is available for selection. This tells me that the slurm component is being opened, even though the param is set. I can check again to ensure that the param is set... On 5/2/08 7:53 AM, "Jeff Squyres" wrote: > (moving to devel list for wider audience) > > Hmm. I thought the UTK stuff from a while ago supposedly changed this > behavior to only open the components that were specifically requested. > > This behavior looks like the *original* MCA behavior -- open them all, > then discard what we don't want (but doesn't necessarily reclaim the > memory because of how dlclose works). > > > On May 2, 2008, at 9:48 AM, Ralph Castain wrote: > >> Yo guys >> >> I've noticed something on the trunk that just doesn't strike me as >> correct. >> If I specify "-mca plm rsh", it is my expectation that (a) only the >> rsh >> component will be opened, and (b) only the rsh module will be >> selected, >> unless that component indicates that it cannot run. >> >> What I am seeing, though, is that -all- the plm components are being >> opened. >> This is not only unnecessary, but consumes memory and leads to >> concern over >> whether or not some other module could become active. >> >> Is this the intended behavior? If so, may I suggest we change it in >> Josh's >> branch prior to bringing it over? >> >> Ralph >> >> >
Re: [OMPI devel] MCA component open
I see what the problem is. In the case of slurm, I don't want -any- components to be opened, even though I am going to call plm open/select. I have to leave that logic in place for those environments that -do- want to specify some backend secondary launcher. So the question is: how do I tell mca_component_open "do not open anything"? If we don't have a mechanism for doing that, can we create one? On 5/2/08 8:02 AM, "Ralph Castain" wrote: > Well, I have a current version of the trunk. I add an MCA param to the > environment indicating that only rsh is to be used by the orted. Yet I get > an output from every orted indicating that slurm (misspelled!) is available > for selection. > > This tells me that the slurm component is being opened, even though the > param is set. > > I can check again to ensure that the param is set... > > > On 5/2/08 7:53 AM, "Jeff Squyres" wrote: > >> (moving to devel list for wider audience) >> >> Hmm. I thought the UTK stuff from a while ago supposedly changed this >> behavior to only open the components that were specifically requested. >> >> This behavior looks like the *original* MCA behavior -- open them all, >> then discard what we don't want (but doesn't necessarily reclaim the >> memory because of how dlclose works). >> >> >> On May 2, 2008, at 9:48 AM, Ralph Castain wrote: >> >>> Yo guys >>> >>> I've noticed something on the trunk that just doesn't strike me as >>> correct. >>> If I specify "-mca plm rsh", it is my expectation that (a) only the >>> rsh >>> component will be opened, and (b) only the rsh module will be >>> selected, >>> unless that component indicates that it cannot run. >>> >>> What I am seeing, though, is that -all- the plm components are being >>> opened. >>> This is not only unnecessary, but consumes memory and leads to >>> concern over >>> whether or not some other module could become active. >>> >>> Is this the intended behavior? If so, may I suggest we change it in >>> Josh's >>> branch prior to bringing it over? >>> >>> Ralph >>> >>> >> > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] MCA component open
I don't believe we have the logic in place to tell mca_component_open 'do not open anything'. (I could be wrong though). Adding such an option might be useful, but we would have to consider how that option should be specified by the user. Currently if you do not set a value (leave empty space in mca-params.conf) then the MCA system takes this to indicate that all components are eligible for selection. If you specify any options then only those options should be opened. We could add a special keyword (such as 'none') to indicate 'open nothing'. What do people think about that? -- Josh On May 2, 2008, at 10:22 AM, Ralph Castain wrote: I see what the problem is. In the case of slurm, I don't want -any- components to be opened, even though I am going to call plm open/ select. I have to leave that logic in place for those environments that -do- want to specify some backend secondary launcher. So the question is: how do I tell mca_component_open "do not open anything"? If we don't have a mechanism for doing that, can we create one? On 5/2/08 8:02 AM, "Ralph Castain" wrote: Well, I have a current version of the trunk. I add an MCA param to the environment indicating that only rsh is to be used by the orted. Yet I get an output from every orted indicating that slurm (misspelled!) is available for selection. This tells me that the slurm component is being opened, even though the param is set. I can check again to ensure that the param is set... On 5/2/08 7:53 AM, "Jeff Squyres" wrote: (moving to devel list for wider audience) Hmm. I thought the UTK stuff from a while ago supposedly changed this behavior to only open the components that were specifically requested. This behavior looks like the *original* MCA behavior -- open them all, then discard what we don't want (but doesn't necessarily reclaim the memory because of how dlclose works). On May 2, 2008, at 9:48 AM, Ralph Castain wrote: Yo guys I've noticed something on the trunk that just doesn't strike me as correct. If I specify "-mca plm rsh", it is my expectation that (a) only the rsh component will be opened, and (b) only the rsh module will be selected, unless that component indicates that it cannot run. What I am seeing, though, is that -all- the plm components are being opened. This is not only unnecessary, but consumes memory and leads to concern over whether or not some other module could become active. Is this the intended behavior? If so, may I suggest we change it in Josh's branch prior to bringing it over? Ralph ___ 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
[OMPI devel] OMPI Mercurial read-only mirror
Taking steps towards Mercurial, we have setup a read-only Mercurial mirror of the official OMPI SVN repository: http://www.open-mpi.org/hg/hgwebdir.cgi/ompi-svn-mirror/ Anything you commit to SVN should show up on the HG mirror within 30 minutes. This mirror is currently *only* the /trunk, /tags, and /branches. It does not include /tmp, /tmp-public, /vendor, or any other top-level SVN directory. The value of this mirror is that you can have distributed HG repositories within your organization and stay in sync with the OMPI SVN trunk (and tags, and branches). We're still working on a way for OMPI core members to publish their own HG trees. Ralph and a few others can publish their HG tree now because they were willing to be guinea pigs, but it's not setup for the general case yet -- give us a little more time to get that going. Since this is a read-only mirror, committing back to SVN is a manual process (e.g., make a patch from your HG tree, apply that patch to an SVN checkout, and then commit). Enjoy! -- Jeff Squyres Cisco Systems
Re: [OMPI devel] MCA component open
I would think that adding a special keyword would be the correct method. I would suggest something with an "ompi" in it, perhaps capitalized so there is no confusion...something like "OMPI-NONE"? On 5/2/08 8:37 AM, "Josh Hursey" wrote: > I don't believe we have the logic in place to tell mca_component_open > 'do not open anything'. (I could be wrong though). > > Adding such an option might be useful, but we would have to consider > how that option should be specified by the user. Currently if you do > not set a value (leave empty space in mca-params.conf) then the MCA > system takes this to indicate that all components are eligible for > selection. If you specify any options then only those options should > be opened. We could add a special keyword (such as 'none') to indicate > 'open nothing'. > > What do people think about that? > > -- Josh > > > On May 2, 2008, at 10:22 AM, Ralph Castain wrote: > >> I see what the problem is. In the case of slurm, I don't want -any- >> components to be opened, even though I am going to call plm open/ >> select. I >> have to leave that logic in place for those environments that -do- >> want to >> specify some backend secondary launcher. >> >> So the question is: how do I tell mca_component_open "do not open >> anything"? >> >> If we don't have a mechanism for doing that, can we create one? >> >> >> On 5/2/08 8:02 AM, "Ralph Castain" wrote: >> >>> Well, I have a current version of the trunk. I add an MCA param to >>> the >>> environment indicating that only rsh is to be used by the orted. >>> Yet I get >>> an output from every orted indicating that slurm (misspelled!) is >>> available >>> for selection. >>> >>> This tells me that the slurm component is being opened, even though >>> the >>> param is set. >>> >>> I can check again to ensure that the param is set... >>> >>> >>> On 5/2/08 7:53 AM, "Jeff Squyres" wrote: >>> (moving to devel list for wider audience) Hmm. I thought the UTK stuff from a while ago supposedly changed this behavior to only open the components that were specifically requested. This behavior looks like the *original* MCA behavior -- open them all, then discard what we don't want (but doesn't necessarily reclaim the memory because of how dlclose works). On May 2, 2008, at 9:48 AM, Ralph Castain wrote: > Yo guys > > I've noticed something on the trunk that just doesn't strike me as > correct. > If I specify "-mca plm rsh", it is my expectation that (a) only the > rsh > component will be opened, and (b) only the rsh module will be > selected, > unless that component indicates that it cannot run. > > What I am seeing, though, is that -all- the plm components are > being > opened. > This is not only unnecessary, but consumes memory and leads to > concern over > whether or not some other module could become active. > > Is this the intended behavior? If so, may I suggest we change it in > Josh's > branch prior to bringing it over? > > Ralph > > >>> >>> >>> ___ >>> 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 > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] OMPI Mercurial read-only mirror
Jeff Squyres wrote: Taking steps towards Mercurial, we have setup a read-only Mercurial mirror of the official OMPI SVN repository: http://www.open-mpi.org/hg/hgwebdir.cgi/ompi-svn-mirror/ Anything you commit to SVN should show up on the HG mirror within 30 minutes. This mirror is currently *only* the /trunk, /tags, and /branches. It does not include /tmp, /tmp-public, /vendor, or any other top-level SVN directory. The value of this mirror is that you can have distributed HG repositories within your organization and stay in sync with the OMPI SVN trunk (and tags, and branches). We're still working on a way for OMPI core members to publish their own HG trees. Ralph and a few others can publish their HG tree now because they were willing to be guinea pigs, but it's not setup for the general case yet -- give us a little more time to get that going. Since this is a read-only mirror, committing back to SVN is a manual process (e.g., make a patch from your HG tree, apply that patch to an SVN checkout, and then commit). Enjoy! Is there a way to make a hg specific /tmp branch? --td
Re: [OMPI devel] OMPI Mercurial read-only mirror
On May 2, 2008, at 11:04 AM, Terry Dontje wrote: Is there a way to make a hg specific /tmp branch? I'm not sure what you're asking...? -- Jeff Squyres Cisco Systems
Re: [OMPI devel] OMPI Mercurial read-only mirror
Jeff Squyres wrote: On May 2, 2008, at 11:04 AM, Terry Dontje wrote: Is there a way to make a hg specific /tmp branch? I'm not sure what you're asking...? Can I make a /tmp branch from the hg read-only branch that is not tied to the svn /tmp branches. --td
Re: [OMPI devel] OMPI Mercurial read-only mirror
Sure: hg clone http://www.open-mpi.org/hg/hgwebdir.cgi/ompi-svn-mirror my-tmp On 5/2/08 9:57 AM, "Terry Dontje" wrote: > Jeff Squyres wrote: >> On May 2, 2008, at 11:04 AM, Terry Dontje wrote: >> >> >>> Is there a way to make a hg specific /tmp branch? >>> >> >> >> I'm not sure what you're asking...? >> >> > Can I make a /tmp branch from the hg read-only branch that is not tied > to the svn /tmp branches. > > --td > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] OMPI Mercurial read-only mirror
> Can I make a /tmp branch from the hg read-only branch that is not tied > to the svn /tmp branches. Why do you want to do that? Mercurial is a fully distributed system, so you could just start committing to one of your local copies of the repository, and I can't see anything missing that a /tmp branch would give you. - R.
Re: [OMPI devel] MCA component open
We could also call it 'null' for the empty set of components? Or maybe OMPI-NULL. Outside of the naming do others this this is a useful feature to implement? -- Josh On May 2, 2008, at 10:51 AM, Ralph Castain wrote: I would think that adding a special keyword would be the correct method. I would suggest something with an "ompi" in it, perhaps capitalized so there is no confusion...something like "OMPI-NONE"? On 5/2/08 8:37 AM, "Josh Hursey" wrote: I don't believe we have the logic in place to tell mca_component_open 'do not open anything'. (I could be wrong though). Adding such an option might be useful, but we would have to consider how that option should be specified by the user. Currently if you do not set a value (leave empty space in mca-params.conf) then the MCA system takes this to indicate that all components are eligible for selection. If you specify any options then only those options should be opened. We could add a special keyword (such as 'none') to indicate 'open nothing'. What do people think about that? -- Josh On May 2, 2008, at 10:22 AM, Ralph Castain wrote: I see what the problem is. In the case of slurm, I don't want -any- components to be opened, even though I am going to call plm open/ select. I have to leave that logic in place for those environments that -do- want to specify some backend secondary launcher. So the question is: how do I tell mca_component_open "do not open anything"? If we don't have a mechanism for doing that, can we create one? On 5/2/08 8:02 AM, "Ralph Castain" wrote: Well, I have a current version of the trunk. I add an MCA param to the environment indicating that only rsh is to be used by the orted. Yet I get an output from every orted indicating that slurm (misspelled!) is available for selection. This tells me that the slurm component is being opened, even though the param is set. I can check again to ensure that the param is set... On 5/2/08 7:53 AM, "Jeff Squyres" wrote: (moving to devel list for wider audience) Hmm. I thought the UTK stuff from a while ago supposedly changed this behavior to only open the components that were specifically requested. This behavior looks like the *original* MCA behavior -- open them all, then discard what we don't want (but doesn't necessarily reclaim the memory because of how dlclose works). On May 2, 2008, at 9:48 AM, Ralph Castain wrote: Yo guys I've noticed something on the trunk that just doesn't strike me as correct. If I specify "-mca plm rsh", it is my expectation that (a) only the rsh component will be opened, and (b) only the rsh module will be selected, unless that component indicates that it cannot run. What I am seeing, though, is that -all- the plm components are being opened. This is not only unnecessary, but consumes memory and leads to concern over whether or not some other module could become active. Is this the intended behavior? If so, may I suggest we change it in Josh's branch prior to bringing it over? Ralph ___ 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 ___ 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
