Re: [OMPI devel] [RFC] mca_base_select()
I -think- I may have found the problem here, but don't have a real test case - try r18429 and see if it works. On 5/11/08 4:32 PM, "Josh Hursey" wrote: > From the stacktrace, this doesn't look like a problem with > base_select, but with 'orte_util_encode_pidmap'. You may want to > start looking there. > > -- Josh > > On May 11, 2008, at 1:30 PM, Lenny Verkhovsky wrote: > >> Hi, >> I tried r 18423 with rank_file component and got seqfault >> ( I increase priority of the component if rmaps_rank_file_path exist) >> >> >> /home/USERS/lenny/OMPI_ORTE_SMD/bin/mpirun -np 4 -hostfile >> hostfile_ompi -mca rmaps_rank_file_path rankfile -mca >> paffinity_base_verbose 5 ./mpi_p_SMD -t bw -output 1 -order 1 >> [witch1:25456] mca:base:select: Querying component [linux] >> [witch1:25456] mca:base:select: Query of component [linux] set >> priority to 10 >> [witch1:25456] mca:base:select: Selected component [linux] >> [witch1:25456] *** Process received signal *** >> [witch1:25456] Signal: Segmentation fault (11) >> [witch1:25456] Signal code: Invalid permissions (2) >> [witch1:25456] Failing at address: 0x2b2875530030 >> [witch1:25456] [ 0] /lib64/libpthread.so.0 [0x2b28759dfc10] >> [witch1:25456] [ 1] /home/USERS/lenny/OMPI_ORTE_SMD/lib/libopen- >> pal.so.0 [0x2b28753e2bb6] >> [witch1:25456] [ 2] /home/USERS/lenny/OMPI_ORTE_SMD/lib/libopen- >> pal.so.0 [0x2b28753e23b6] >> [witch1:25456] [ 3] /home/USERS/lenny/OMPI_ORTE_SMD/lib/libopen- >> pal.so.0 [0x2b28753e22fd] >> [witch1:25456] [ 4] /home/USERS/lenny/OMPI_ORTE_SMD/lib/libopen- >> rte.so.0(orte_util_encode_pidmap+0x2f4) [0x2b287527f412] >> [witch1:25456] [ 5] /home/USERS/lenny/OMPI_ORTE_SMD/lib/libopen- >> rte.so.0(orte_odls_base_default_get_add_procs_data+0x989) >> [0x2b28752934f5] >> [witch1:25456] [ 6] /home/USERS/lenny/OMPI_ORTE_SMD/lib/libopen- >> rte.so.0(orte_plm_base_launch_apps+0x1a3) [0x2b287529e60b] >> [witch1:25456] [ 7] /home/USERS/lenny/OMPI_ORTE_SMD/lib/openmpi/ >> mca_plm_rsh.so [0x2b287612f788] >> [witch1:25456] [ 8] /home/USERS/lenny/OMPI_ORTE_SMD/bin/mpirun >> [0x4032bf] >> [witch1:25456] [ 9] /home/USERS/lenny/OMPI_ORTE_SMD/bin/mpirun >> [0x402b53] >> [witch1:25456] [10] /lib64/libc.so.6(__libc_start_main+0xf4) >> [0x2b2875b06154] >> [witch1:25456] [11] /home/USERS/lenny/OMPI_ORTE_SMD/bin/mpirun >> [0x402aa9] >> [witch1:25456] *** End of error message *** >> Segmentation fault >> >> >> >> >> On Tue, May 6, 2008 at 9:09 PM, Josh Hursey >> wrote: >> This has been committed in r18381 >> >> Please let me know if you have any problems with this commit. >> >> Cheers, >> Josh >> >> On May 5, 2008, at 10:41 AM, Josh Hursey wrote: >> >>> Awesome. >>> >>> The branch is updated to the latest trunk head. I encourage folks to >>> check out this repository and make sure that it builds on their >>> system. A normal build of the branch should be enough to find out if >>> there are any cut-n-paste problems (though I tried to be careful, >>> mistakes do happen). >>> >>> I haven't heard any problems so this is looking like it will come in >>> tomorrow after the teleconf. I'll ask again there to see if there >> are >>> any voices of concern. >>> >>> Cheers, >>> Josh >>> >>> On May 5, 2008, at 9:58 AM, Jeff Squyres wrote: >>> This all sounds good to me! On Apr 29, 2008, at 6:35 PM, Josh Hursey wrote: > What: Add mca_base_select() and adjust frameworks & components to > use > it. > Why: Consolidation of code for general goodness. > Where: https://svn.open-mpi.org/svn/ompi/tmp-public/jjh-mca-play > When: Code ready now. Documentation ready soon. > Timeout: May 6, 2008 (After teleconf) [1 week] > > Discussion: > --- > For a number of years a few developers have been talking about > creating a MCA base component selection function. For various > reasons > this was never implemented. Recently I decided to give it a try. > > A base select function will allow Open MPI to provide completely > consistent selection behavior for many of its frameworks (18 of 31 > to > be exact at the moment). The primary goal of this work is to > improving > code maintainability through code reuse. Other benefits also >> result > such as a slightly smaller memory footprint. > > The mca_base_select() function represented the most commonly used > logic for component selection: Select the one component with the > highest priority and close all of the not selected components. >> This > function can be found at the path below in the branch: > opal/mca/base/mca_base_components_select.c > > To support this I had to formalize a query() function in the > mca_base_component_t of the form: > int mca_base_query_component_fn(mca_base_module_t **module, int > *priority); > > This function is specified after the open and close component > functions in this structure as to allow compatibility with > fram
Re: [OMPI devel] [RFC] mca_base_select()
From the stacktrace, this doesn't look like a problem with base_select, but with 'orte_util_encode_pidmap'. You may want to start looking there. -- Josh On May 11, 2008, at 1:30 PM, Lenny Verkhovsky wrote: Hi, I tried r 18423 with rank_file component and got seqfault ( I increase priority of the component if rmaps_rank_file_path exist) /home/USERS/lenny/OMPI_ORTE_SMD/bin/mpirun -np 4 -hostfile hostfile_ompi -mca rmaps_rank_file_path rankfile -mca paffinity_base_verbose 5 ./mpi_p_SMD -t bw -output 1 -order 1 [witch1:25456] mca:base:select: Querying component [linux] [witch1:25456] mca:base:select: Query of component [linux] set priority to 10 [witch1:25456] mca:base:select: Selected component [linux] [witch1:25456] *** Process received signal *** [witch1:25456] Signal: Segmentation fault (11) [witch1:25456] Signal code: Invalid permissions (2) [witch1:25456] Failing at address: 0x2b2875530030 [witch1:25456] [ 0] /lib64/libpthread.so.0 [0x2b28759dfc10] [witch1:25456] [ 1] /home/USERS/lenny/OMPI_ORTE_SMD/lib/libopen- pal.so.0 [0x2b28753e2bb6] [witch1:25456] [ 2] /home/USERS/lenny/OMPI_ORTE_SMD/lib/libopen- pal.so.0 [0x2b28753e23b6] [witch1:25456] [ 3] /home/USERS/lenny/OMPI_ORTE_SMD/lib/libopen- pal.so.0 [0x2b28753e22fd] [witch1:25456] [ 4] /home/USERS/lenny/OMPI_ORTE_SMD/lib/libopen- rte.so.0(orte_util_encode_pidmap+0x2f4) [0x2b287527f412] [witch1:25456] [ 5] /home/USERS/lenny/OMPI_ORTE_SMD/lib/libopen- rte.so.0(orte_odls_base_default_get_add_procs_data+0x989) [0x2b28752934f5] [witch1:25456] [ 6] /home/USERS/lenny/OMPI_ORTE_SMD/lib/libopen- rte.so.0(orte_plm_base_launch_apps+0x1a3) [0x2b287529e60b] [witch1:25456] [ 7] /home/USERS/lenny/OMPI_ORTE_SMD/lib/openmpi/ mca_plm_rsh.so [0x2b287612f788] [witch1:25456] [ 8] /home/USERS/lenny/OMPI_ORTE_SMD/bin/mpirun [0x4032bf] [witch1:25456] [ 9] /home/USERS/lenny/OMPI_ORTE_SMD/bin/mpirun [0x402b53] [witch1:25456] [10] /lib64/libc.so.6(__libc_start_main+0xf4) [0x2b2875b06154] [witch1:25456] [11] /home/USERS/lenny/OMPI_ORTE_SMD/bin/mpirun [0x402aa9] [witch1:25456] *** End of error message *** Segmentation fault On Tue, May 6, 2008 at 9:09 PM, Josh Hursey wrote: This has been committed in r18381 Please let me know if you have any problems with this commit. Cheers, Josh On May 5, 2008, at 10:41 AM, Josh Hursey wrote: > Awesome. > > The branch is updated to the latest trunk head. I encourage folks to > check out this repository and make sure that it builds on their > system. A normal build of the branch should be enough to find out if > there are any cut-n-paste problems (though I tried to be careful, > mistakes do happen). > > I haven't heard any problems so this is looking like it will come in > tomorrow after the teleconf. I'll ask again there to see if there are > any voices of concern. > > Cheers, > Josh > > On May 5, 2008, at 9:58 AM, Jeff Squyres wrote: > >> This all sounds good to me! >> >> On Apr 29, 2008, at 6:35 PM, Josh Hursey wrote: >> >>> What: Add mca_base_select() and adjust frameworks & components to >>> use >>> it. >>> Why: Consolidation of code for general goodness. >>> Where: https://svn.open-mpi.org/svn/ompi/tmp-public/jjh-mca-play >>> When: Code ready now. Documentation ready soon. >>> Timeout: May 6, 2008 (After teleconf) [1 week] >>> >>> Discussion: >>> --- >>> For a number of years a few developers have been talking about >>> creating a MCA base component selection function. For various >>> reasons >>> this was never implemented. Recently I decided to give it a try. >>> >>> A base select function will allow Open MPI to provide completely >>> consistent selection behavior for many of its frameworks (18 of 31 >>> to >>> be exact at the moment). The primary goal of this work is to >>> improving >>> code maintainability through code reuse. Other benefits also result >>> such as a slightly smaller memory footprint. >>> >>> The mca_base_select() function represented the most commonly used >>> logic for component selection: Select the one component with the >>> highest priority and close all of the not selected components. This >>> function can be found at the path below in the branch: >>> opal/mca/base/mca_base_components_select.c >>> >>> To support this I had to formalize a query() function in the >>> mca_base_component_t of the form: >>> int mca_base_query_component_fn(mca_base_module_t **module, int >>> *priority); >>> >>> This function is specified after the open and close component >>> functions in this structure as to allow compatibility with >>> frameworks >>> that do not use the base selection logic. Frameworks that do *not* >>> use >>> this function are *not* effected by this commit. However, every >>> component in the frameworks that use the mca_base_select function >>> must >>> adjust their component query function to fit that specified above. >>> >>> 18 frameworks in Open MPI have been changed. I have updated all of >>> the >>> components in the 18 frameworks available in t
Re: [OMPI devel] [RFC] mca_base_select()
Hi, I tried r 18423 with rank_file component and got seqfault ( I increase priority of the component if rmaps_rank_file_path exist) /home/USERS/lenny/OMPI_ORTE_SMD/bin/mpirun -np 4 -hostfile hostfile_ompi -mca rmaps_rank_file_path rankfile -mca paffinity_base_verbose 5 ./mpi_p_SMD -t bw -output 1 -order 1 [witch1:25456] mca:base:select: Querying component [linux] [witch1:25456] mca:base:select: Query of component [linux] set priority to 10 [witch1:25456] mca:base:select: Selected component [linux] [witch1:25456] *** Process received signal *** [witch1:25456] Signal: Segmentation fault (11) [witch1:25456] Signal code: Invalid permissions (2) [witch1:25456] Failing at address: 0x2b2875530030 [witch1:25456] [ 0] /lib64/libpthread.so.0 [0x2b28759dfc10] [witch1:25456] [ 1] /home/USERS/lenny/OMPI_ORTE_SMD/lib/libopen-pal.so.0 [0x2b28753e2bb6] [witch1:25456] [ 2] /home/USERS/lenny/OMPI_ORTE_SMD/lib/libopen-pal.so.0 [0x2b28753e23b6] [witch1:25456] [ 3] /home/USERS/lenny/OMPI_ORTE_SMD/lib/libopen-pal.so.0 [0x2b28753e22fd] [witch1:25456] [ 4] /home/USERS/lenny/OMPI_ORTE_SMD/lib/libopen-rte.so.0(orte_util_encode_pidmap+0x2f4) [0x2b287527f412] [witch1:25456] [ 5] /home/USERS/lenny/OMPI_ORTE_SMD/lib/libopen-rte.so.0(orte_odls_base_default_get_add_procs_data+0x989) [0x2b28752934f5] [witch1:25456] [ 6] /home/USERS/lenny/OMPI_ORTE_SMD/lib/libopen-rte.so.0(orte_plm_base_launch_apps+0x1a3) [0x2b287529e60b] [witch1:25456] [ 7] /home/USERS/lenny/OMPI_ORTE_SMD/lib/openmpi/mca_plm_rsh.so [0x2b287612f788] [witch1:25456] [ 8] /home/USERS/lenny/OMPI_ORTE_SMD/bin/mpirun [0x4032bf] [witch1:25456] [ 9] /home/USERS/lenny/OMPI_ORTE_SMD/bin/mpirun [0x402b53] [witch1:25456] [10] /lib64/libc.so.6(__libc_start_main+0xf4) [0x2b2875b06154] [witch1:25456] [11] /home/USERS/lenny/OMPI_ORTE_SMD/bin/mpirun [0x402aa9] [witch1:25456] *** End of error message *** Segmentation fault On Tue, May 6, 2008 at 9:09 PM, Josh Hursey wrote: > This has been committed in r18381 > > Please let me know if you have any problems with this commit. > > Cheers, > Josh > > On May 5, 2008, at 10:41 AM, Josh Hursey wrote: > > > Awesome. > > > > The branch is updated to the latest trunk head. I encourage folks to > > check out this repository and make sure that it builds on their > > system. A normal build of the branch should be enough to find out if > > there are any cut-n-paste problems (though I tried to be careful, > > mistakes do happen). > > > > I haven't heard any problems so this is looking like it will come in > > tomorrow after the teleconf. I'll ask again there to see if there are > > any voices of concern. > > > > Cheers, > > Josh > > > > On May 5, 2008, at 9:58 AM, Jeff Squyres wrote: > > > >> This all sounds good to me! > >> > >> On Apr 29, 2008, at 6:35 PM, Josh Hursey wrote: > >> > >>> What: Add mca_base_select() and adjust frameworks & components to > >>> use > >>> it. > >>> Why: Consolidation of code for general goodness. > >>> Where: https://svn.open-mpi.org/svn/ompi/tmp-public/jjh-mca-play > >>> When: Code ready now. Documentation ready soon. > >>> Timeout: May 6, 2008 (After teleconf) [1 week] > >>> > >>> Discussion: > >>> --- > >>> For a number of years a few developers have been talking about > >>> creating a MCA base component selection function. For various > >>> reasons > >>> this was never implemented. Recently I decided to give it a try. > >>> > >>> A base select function will allow Open MPI to provide completely > >>> consistent selection behavior for many of its frameworks (18 of 31 > >>> to > >>> be exact at the moment). The primary goal of this work is to > >>> improving > >>> code maintainability through code reuse. Other benefits also result > >>> such as a slightly smaller memory footprint. > >>> > >>> The mca_base_select() function represented the most commonly used > >>> logic for component selection: Select the one component with the > >>> highest priority and close all of the not selected components. This > >>> function can be found at the path below in the branch: > >>> opal/mca/base/mca_base_components_select.c > >>> > >>> To support this I had to formalize a query() function in the > >>> mca_base_component_t of the form: > >>> int mca_base_query_component_fn(mca_base_module_t **module, int > >>> *priority); > >>> > >>> This function is specified after the open and close component > >>> functions in this structure as to allow compatibility with > >>> frameworks > >>> that do not use the base selection logic. Frameworks that do *not* > >>> use > >>> this function are *not* effected by this commit. However, every > >>> component in the frameworks that use the mca_base_select function > >>> must > >>> adjust their component query function to fit that specified above. > >>> > >>> 18 frameworks in Open MPI have been changed. I have updated all of > >>> the > >>> components in the 18 frameworks available in the trunk on my branch. > >>> The effected frameworks are: > >>> - OPAL Carto > >>> - OPAL crs > >>> - OPAL ma
Re: [OMPI devel] [RFC] mca_base_select()
Not quite, Josh - I fixed it in our branch. Will send you a revised patch that does the job off-list for your review. Thanks Ralph On 5/9/08 9:35 AM, "Josh Hursey" wrote: > Ok I think I understand the problem a bit better now. I attached a > patch that should fix this, but I want you to check it out before I > commit just to make sure. > > If you specify '-mca filter xml' on the command line then only the > 'xml' component should be opened by mca_base_open. The problem was > that the selection logic used -1 as the lowest acceptable priority, > which conflicted with the set priority of the 'xml' component. This > patch sets this value to INT32_MIN which should be well below any > negative priority that a component would set for itself. > > Let me know if this works for you and I'll commit it. > > Cheers, > Josh > > > > On May 9, 2008, at 11:14 AM, Ralph Castain wrote: > >> Sure - take a look at the hg repository Jeff and I are working on: >> >> http://www.open-mpi.org/hg/hgwebdir.cgi/rhc/channel >> >> Te opal/mca/filter framework illustrates the problem. I have one >> component >> in there right now, with a default module defined in the base. That >> component must only be selected if the user calls it. With the current >> select logic, I can't do this - if the priority is >=0, then it >> always is >> automatically selected. Priority < 0, never selectable even if >> specified. >> >> Thanks >> Ralph >> >> >> >> On 5/9/08 8:52 AM, "Josh Hursey" wrote: >> >>> Ralph, >>> >>> Can you give me an example of a component that I can look at? It will >>> allow me to test the fix before committing, and to better understand >>> the problem. >>> >>> -- Josh >>> >>> On May 9, 2008, at 10:41 AM, Ralph Castain wrote: >>> I just hit a problem with this logic - should be a minor change. We have several frameworks where we have components that are only allowed be selected if the user specifically requests them by stating -mca foo bar. Because it is possible for there to be no other components that want to be selected, and because it is permissible for no components to be selected for that framework, we set bar's priority to be -1. The new select logic will not allow a negative priority to be selected, even if the user specifically requested that component. If we set the priority to be 0, then the system will allow the component to be automatically selected. This is not allowed as it can lead to bad behavior. So what we need the select system to do is say "if someone specified a specific component, don't worry about the returned priority - just use it" Josh: could you please modify this? Thanks! Ralph On 5/8/08 7:04 PM, "Pak Lui" wrote: > Thanks very much Josh! Will try it out soon. > > Josh Hursey wrote: >> Sorry about that. I didn't test that type of option. It should be >> working in r18418. Let me know if you see any more issues. >> >> -- Josh >> >> On May 8, 2008, at 6:04 PM, Pak Lui wrote: >> >>> I think I have a problem but I am not sure. I used to be able to >>> use the >>> circumflex (^) to switch between the gridengine launcher and the >>> ssh >>> launchers by doing something like this, e.g. -mca plm >>> ^gridengine, to >>> exclude some of the components plm (and also in ras). It doesn't >>> seem >>> like the 'negate' is in mca_base_component anymore. I guess I >>> just have >>> to spell out which component I want explicitly... >>> >>> Josh Hursey wrote: This has been committed in r18381 Please let me know if you have any problems with this commit. Cheers, Josh On May 5, 2008, at 10:41 AM, Josh Hursey wrote: > Awesome. > > The branch is updated to the latest trunk head. I encourage > folks to > check out this repository and make sure that it builds on their > system. A normal build of the branch should be enough to find > out if > there are any cut-n-paste problems (though I tried to be > careful, > mistakes do happen). > > I haven't heard any problems so this is looking like it will > come in > tomorrow after the teleconf. I'll ask again there to see if > there are > any voices of concern. > > Cheers, > Josh > > On May 5, 2008, at 9:58 AM, Jeff Squyres wrote: > >> This all sounds good to me! >> >> On Apr 29, 2008, at 6:35 PM, Josh Hursey wrote: >> >>> What: Add mca_base_select() and adjust frameworks & >>> components to >>> use >>> it. >>> Why: Consolidation of code for general
Re: [OMPI devel] [RFC] mca_base_select()
Ok I think I understand the problem a bit better now. I attached a patch that should fix this, but I want you to check it out before I commit just to make sure. If you specify '-mca filter xml' on the command line then only the 'xml' component should be opened by mca_base_open. The problem was that the selection logic used -1 as the lowest acceptable priority, which conflicted with the set priority of the 'xml' component. This patch sets this value to INT32_MIN which should be well below any negative priority that a component would set for itself. Let me know if this works for you and I'll commit it. Cheers, Josh select.patch Description: Binary data On May 9, 2008, at 11:14 AM, Ralph Castain wrote: Sure - take a look at the hg repository Jeff and I are working on: http://www.open-mpi.org/hg/hgwebdir.cgi/rhc/channel Te opal/mca/filter framework illustrates the problem. I have one component in there right now, with a default module defined in the base. That component must only be selected if the user calls it. With the current select logic, I can't do this - if the priority is >=0, then it always is automatically selected. Priority < 0, never selectable even if specified. Thanks Ralph On 5/9/08 8:52 AM, "Josh Hursey" wrote: Ralph, Can you give me an example of a component that I can look at? It will allow me to test the fix before committing, and to better understand the problem. -- Josh On May 9, 2008, at 10:41 AM, Ralph Castain wrote: I just hit a problem with this logic - should be a minor change. We have several frameworks where we have components that are only allowed be selected if the user specifically requests them by stating -mca foo bar. Because it is possible for there to be no other components that want to be selected, and because it is permissible for no components to be selected for that framework, we set bar's priority to be -1. The new select logic will not allow a negative priority to be selected, even if the user specifically requested that component. If we set the priority to be 0, then the system will allow the component to be automatically selected. This is not allowed as it can lead to bad behavior. So what we need the select system to do is say "if someone specified a specific component, don't worry about the returned priority - just use it" Josh: could you please modify this? Thanks! Ralph On 5/8/08 7:04 PM, "Pak Lui" wrote: Thanks very much Josh! Will try it out soon. Josh Hursey wrote: Sorry about that. I didn't test that type of option. It should be working in r18418. Let me know if you see any more issues. -- Josh On May 8, 2008, at 6:04 PM, Pak Lui wrote: I think I have a problem but I am not sure. I used to be able to use the circumflex (^) to switch between the gridengine launcher and the ssh launchers by doing something like this, e.g. -mca plm ^gridengine, to exclude some of the components plm (and also in ras). It doesn't seem like the 'negate' is in mca_base_component anymore. I guess I just have to spell out which component I want explicitly... Josh Hursey wrote: This has been committed in r18381 Please let me know if you have any problems with this commit. Cheers, Josh On May 5, 2008, at 10:41 AM, Josh Hursey wrote: Awesome. The branch is updated to the latest trunk head. I encourage folks to check out this repository and make sure that it builds on their system. A normal build of the branch should be enough to find out if there are any cut-n-paste problems (though I tried to be careful, mistakes do happen). I haven't heard any problems so this is looking like it will come in tomorrow after the teleconf. I'll ask again there to see if there are any voices of concern. Cheers, Josh On May 5, 2008, at 9:58 AM, Jeff Squyres wrote: This all sounds good to me! On Apr 29, 2008, at 6:35 PM, Josh Hursey wrote: What: Add mca_base_select() and adjust frameworks & components to use it. Why: Consolidation of code for general goodness. Where: https://svn.open-mpi.org/svn/ompi/tmp-public/jjh-mca- play When: Code ready now. Documentation ready soon. Timeout: May 6, 2008 (After teleconf) [1 week] Discussion: --- For a number of years a few developers have been talking about creating a MCA base component selection function. For various reasons this was never implemented. Recently I decided to give it a try. A base select function will allow Open MPI to provide completely consistent selection behavior for many of its frameworks (18 of 31 to be exact at the moment). The primary goal of this work is to improving code maintainability through code reuse. Other benefits also result such as a slightly smaller memory footprint. The mca_base_select() function represented the most commonly used logic for component selection: Select the one component with the highest priority and close all of the not selected components. This function can be found at the path below in the branch: opal/mca/base/
Re: [OMPI devel] [RFC] mca_base_select()
Sure - take a look at the hg repository Jeff and I are working on: http://www.open-mpi.org/hg/hgwebdir.cgi/rhc/channel Te opal/mca/filter framework illustrates the problem. I have one component in there right now, with a default module defined in the base. That component must only be selected if the user calls it. With the current select logic, I can't do this - if the priority is >=0, then it always is automatically selected. Priority < 0, never selectable even if specified. Thanks Ralph On 5/9/08 8:52 AM, "Josh Hursey" wrote: > Ralph, > > Can you give me an example of a component that I can look at? It will > allow me to test the fix before committing, and to better understand > the problem. > > -- Josh > > On May 9, 2008, at 10:41 AM, Ralph Castain wrote: > >> I just hit a problem with this logic - should be a minor change. >> >> We have several frameworks where we have components that are only >> allowed be >> selected if the user specifically requests them by stating -mca foo >> bar. >> Because it is possible for there to be no other components that want >> to be >> selected, and because it is permissible for no components to be >> selected for >> that framework, we set bar's priority to be -1. >> >> The new select logic will not allow a negative priority to be >> selected, even >> if the user specifically requested that component. >> >> If we set the priority to be 0, then the system will allow the >> component to >> be automatically selected. This is not allowed as it can lead to bad >> behavior. >> >> So what we need the select system to do is say "if someone specified a >> specific component, don't worry about the returned priority - just >> use it" >> >> Josh: could you please modify this? >> >> Thanks! >> Ralph >> >> >> >> On 5/8/08 7:04 PM, "Pak Lui" wrote: >> >>> Thanks very much Josh! Will try it out soon. >>> >>> Josh Hursey wrote: Sorry about that. I didn't test that type of option. It should be working in r18418. Let me know if you see any more issues. -- Josh On May 8, 2008, at 6:04 PM, Pak Lui wrote: > I think I have a problem but I am not sure. I used to be able to > use the > circumflex (^) to switch between the gridengine launcher and the > ssh > launchers by doing something like this, e.g. -mca plm > ^gridengine, to > exclude some of the components plm (and also in ras). It doesn't > seem > like the 'negate' is in mca_base_component anymore. I guess I > just have > to spell out which component I want explicitly... > > Josh Hursey wrote: >> This has been committed in r18381 >> >> Please let me know if you have any problems with this commit. >> >> Cheers, >> Josh >> >> On May 5, 2008, at 10:41 AM, Josh Hursey wrote: >> >>> Awesome. >>> >>> The branch is updated to the latest trunk head. I encourage >>> folks to >>> check out this repository and make sure that it builds on their >>> system. A normal build of the branch should be enough to find >>> out if >>> there are any cut-n-paste problems (though I tried to be careful, >>> mistakes do happen). >>> >>> I haven't heard any problems so this is looking like it will >>> come in >>> tomorrow after the teleconf. I'll ask again there to see if >>> there are >>> any voices of concern. >>> >>> Cheers, >>> Josh >>> >>> On May 5, 2008, at 9:58 AM, Jeff Squyres wrote: >>> This all sounds good to me! On Apr 29, 2008, at 6:35 PM, Josh Hursey wrote: > What: Add mca_base_select() and adjust frameworks & > components to > use > it. > Why: Consolidation of code for general goodness. > Where: https://svn.open-mpi.org/svn/ompi/tmp-public/jjh-mca- > play > When: Code ready now. Documentation ready soon. > Timeout: May 6, 2008 (After teleconf) [1 week] > > Discussion: > --- > For a number of years a few developers have been talking about > creating a MCA base component selection function. For various > reasons > this was never implemented. Recently I decided to give it a > try. > > A base select function will allow Open MPI to provide > completely > consistent selection behavior for many of its frameworks (18 > of 31 > to > be exact at the moment). The primary goal of this work is to > improving > code maintainability through code reuse. Other benefits also > result > such as a slightly smaller memory footprint. > > The mca_base_select() function represented the most commonly > used > logic for component selection: Select the one component with > the > highest priority and close all of the not se
Re: [OMPI devel] [RFC] mca_base_select()
Ralph, Can you give me an example of a component that I can look at? It will allow me to test the fix before committing, and to better understand the problem. -- Josh On May 9, 2008, at 10:41 AM, Ralph Castain wrote: I just hit a problem with this logic - should be a minor change. We have several frameworks where we have components that are only allowed be selected if the user specifically requests them by stating -mca foo bar. Because it is possible for there to be no other components that want to be selected, and because it is permissible for no components to be selected for that framework, we set bar's priority to be -1. The new select logic will not allow a negative priority to be selected, even if the user specifically requested that component. If we set the priority to be 0, then the system will allow the component to be automatically selected. This is not allowed as it can lead to bad behavior. So what we need the select system to do is say "if someone specified a specific component, don't worry about the returned priority - just use it" Josh: could you please modify this? Thanks! Ralph On 5/8/08 7:04 PM, "Pak Lui" wrote: Thanks very much Josh! Will try it out soon. Josh Hursey wrote: Sorry about that. I didn't test that type of option. It should be working in r18418. Let me know if you see any more issues. -- Josh On May 8, 2008, at 6:04 PM, Pak Lui wrote: I think I have a problem but I am not sure. I used to be able to use the circumflex (^) to switch between the gridengine launcher and the ssh launchers by doing something like this, e.g. -mca plm ^gridengine, to exclude some of the components plm (and also in ras). It doesn't seem like the 'negate' is in mca_base_component anymore. I guess I just have to spell out which component I want explicitly... Josh Hursey wrote: This has been committed in r18381 Please let me know if you have any problems with this commit. Cheers, Josh On May 5, 2008, at 10:41 AM, Josh Hursey wrote: Awesome. The branch is updated to the latest trunk head. I encourage folks to check out this repository and make sure that it builds on their system. A normal build of the branch should be enough to find out if there are any cut-n-paste problems (though I tried to be careful, mistakes do happen). I haven't heard any problems so this is looking like it will come in tomorrow after the teleconf. I'll ask again there to see if there are any voices of concern. Cheers, Josh On May 5, 2008, at 9:58 AM, Jeff Squyres wrote: This all sounds good to me! On Apr 29, 2008, at 6:35 PM, Josh Hursey wrote: What: Add mca_base_select() and adjust frameworks & components to use it. Why: Consolidation of code for general goodness. Where: https://svn.open-mpi.org/svn/ompi/tmp-public/jjh-mca- play When: Code ready now. Documentation ready soon. Timeout: May 6, 2008 (After teleconf) [1 week] Discussion: --- For a number of years a few developers have been talking about creating a MCA base component selection function. For various reasons this was never implemented. Recently I decided to give it a try. A base select function will allow Open MPI to provide completely consistent selection behavior for many of its frameworks (18 of 31 to be exact at the moment). The primary goal of this work is to improving code maintainability through code reuse. Other benefits also result such as a slightly smaller memory footprint. The mca_base_select() function represented the most commonly used logic for component selection: Select the one component with the highest priority and close all of the not selected components. This function can be found at the path below in the branch: opal/mca/base/mca_base_components_select.c To support this I had to formalize a query() function in the mca_base_component_t of the form: int mca_base_query_component_fn(mca_base_module_t **module, int *priority); This function is specified after the open and close component functions in this structure as to allow compatibility with frameworks that do not use the base selection logic. Frameworks that do *not* use this function are *not* effected by this commit. However, every component in the frameworks that use the mca_base_select function must adjust their component query function to fit that specified above. 18 frameworks in Open MPI have been changed. I have updated all of the components in the 18 frameworks available in the trunk on my branch. The effected frameworks are: - OPAL Carto - OPAL crs - OPAL maffinity - OPAL memchecker - OPAL paffinity - ORTE errmgr - ORTE ess - ORTE Filem - ORTE grpcomm - ORTE odls - ORTE pml - ORTE ras - ORTE rmaps - ORTE routed - ORTE snapc - OMPI crcp - OMPI dpm - OMPI pubsub There was a question of the memory footprint change as a result of this commit. I used 'pmap' to determine process memory footprint of a hello world MPI program. Static and Shared build numb
Re: [OMPI devel] [RFC] mca_base_select()
I just hit a problem with this logic - should be a minor change. We have several frameworks where we have components that are only allowed be selected if the user specifically requests them by stating -mca foo bar. Because it is possible for there to be no other components that want to be selected, and because it is permissible for no components to be selected for that framework, we set bar's priority to be -1. The new select logic will not allow a negative priority to be selected, even if the user specifically requested that component. If we set the priority to be 0, then the system will allow the component to be automatically selected. This is not allowed as it can lead to bad behavior. So what we need the select system to do is say "if someone specified a specific component, don't worry about the returned priority - just use it" Josh: could you please modify this? Thanks! Ralph On 5/8/08 7:04 PM, "Pak Lui" wrote: > Thanks very much Josh! Will try it out soon. > > Josh Hursey wrote: >> Sorry about that. I didn't test that type of option. It should be >> working in r18418. Let me know if you see any more issues. >> >> -- Josh >> >> On May 8, 2008, at 6:04 PM, Pak Lui wrote: >> >>> I think I have a problem but I am not sure. I used to be able to use the >>> circumflex (^) to switch between the gridengine launcher and the ssh >>> launchers by doing something like this, e.g. -mca plm ^gridengine, to >>> exclude some of the components plm (and also in ras). It doesn't seem >>> like the 'negate' is in mca_base_component anymore. I guess I just have >>> to spell out which component I want explicitly... >>> >>> Josh Hursey wrote: This has been committed in r18381 Please let me know if you have any problems with this commit. Cheers, Josh On May 5, 2008, at 10:41 AM, Josh Hursey wrote: > Awesome. > > The branch is updated to the latest trunk head. I encourage folks to > check out this repository and make sure that it builds on their > system. A normal build of the branch should be enough to find out if > there are any cut-n-paste problems (though I tried to be careful, > mistakes do happen). > > I haven't heard any problems so this is looking like it will come in > tomorrow after the teleconf. I'll ask again there to see if there are > any voices of concern. > > Cheers, > Josh > > On May 5, 2008, at 9:58 AM, Jeff Squyres wrote: > >> This all sounds good to me! >> >> On Apr 29, 2008, at 6:35 PM, Josh Hursey wrote: >> >>> What: Add mca_base_select() and adjust frameworks & components to >>> use >>> it. >>> Why: Consolidation of code for general goodness. >>> Where: https://svn.open-mpi.org/svn/ompi/tmp-public/jjh-mca-play >>> When: Code ready now. Documentation ready soon. >>> Timeout: May 6, 2008 (After teleconf) [1 week] >>> >>> Discussion: >>> --- >>> For a number of years a few developers have been talking about >>> creating a MCA base component selection function. For various >>> reasons >>> this was never implemented. Recently I decided to give it a try. >>> >>> A base select function will allow Open MPI to provide completely >>> consistent selection behavior for many of its frameworks (18 of 31 >>> to >>> be exact at the moment). The primary goal of this work is to >>> improving >>> code maintainability through code reuse. Other benefits also result >>> such as a slightly smaller memory footprint. >>> >>> The mca_base_select() function represented the most commonly used >>> logic for component selection: Select the one component with the >>> highest priority and close all of the not selected components. This >>> function can be found at the path below in the branch: >>> opal/mca/base/mca_base_components_select.c >>> >>> To support this I had to formalize a query() function in the >>> mca_base_component_t of the form: >>> int mca_base_query_component_fn(mca_base_module_t **module, int >>> *priority); >>> >>> This function is specified after the open and close component >>> functions in this structure as to allow compatibility with >>> frameworks >>> that do not use the base selection logic. Frameworks that do *not* >>> use >>> this function are *not* effected by this commit. However, every >>> component in the frameworks that use the mca_base_select function >>> must >>> adjust their component query function to fit that specified above. >>> >>> 18 frameworks in Open MPI have been changed. I have updated all of >>> the >>> components in the 18 frameworks available in the trunk on my branch. >>> The effected frameworks are: >>> - OPAL Carto >>> - OPAL crs >>> - OPAL maffinity >>> - OPAL memchecker >>> - OPAL paffinity >>> - ORT
Re: [OMPI devel] [RFC] mca_base_select()
Thanks very much Josh! Will try it out soon. Josh Hursey wrote: Sorry about that. I didn't test that type of option. It should be working in r18418. Let me know if you see any more issues. -- Josh On May 8, 2008, at 6:04 PM, Pak Lui wrote: I think I have a problem but I am not sure. I used to be able to use the circumflex (^) to switch between the gridengine launcher and the ssh launchers by doing something like this, e.g. -mca plm ^gridengine, to exclude some of the components plm (and also in ras). It doesn't seem like the 'negate' is in mca_base_component anymore. I guess I just have to spell out which component I want explicitly... Josh Hursey wrote: This has been committed in r18381 Please let me know if you have any problems with this commit. Cheers, Josh On May 5, 2008, at 10:41 AM, Josh Hursey wrote: Awesome. The branch is updated to the latest trunk head. I encourage folks to check out this repository and make sure that it builds on their system. A normal build of the branch should be enough to find out if there are any cut-n-paste problems (though I tried to be careful, mistakes do happen). I haven't heard any problems so this is looking like it will come in tomorrow after the teleconf. I'll ask again there to see if there are any voices of concern. Cheers, Josh On May 5, 2008, at 9:58 AM, Jeff Squyres wrote: This all sounds good to me! On Apr 29, 2008, at 6:35 PM, Josh Hursey wrote: What: Add mca_base_select() and adjust frameworks & components to use it. Why: Consolidation of code for general goodness. Where: https://svn.open-mpi.org/svn/ompi/tmp-public/jjh-mca-play When: Code ready now. Documentation ready soon. Timeout: May 6, 2008 (After teleconf) [1 week] Discussion: --- For a number of years a few developers have been talking about creating a MCA base component selection function. For various reasons this was never implemented. Recently I decided to give it a try. A base select function will allow Open MPI to provide completely consistent selection behavior for many of its frameworks (18 of 31 to be exact at the moment). The primary goal of this work is to improving code maintainability through code reuse. Other benefits also result such as a slightly smaller memory footprint. The mca_base_select() function represented the most commonly used logic for component selection: Select the one component with the highest priority and close all of the not selected components. This function can be found at the path below in the branch: opal/mca/base/mca_base_components_select.c To support this I had to formalize a query() function in the mca_base_component_t of the form: int mca_base_query_component_fn(mca_base_module_t **module, int *priority); This function is specified after the open and close component functions in this structure as to allow compatibility with frameworks that do not use the base selection logic. Frameworks that do *not* use this function are *not* effected by this commit. However, every component in the frameworks that use the mca_base_select function must adjust their component query function to fit that specified above. 18 frameworks in Open MPI have been changed. I have updated all of the components in the 18 frameworks available in the trunk on my branch. The effected frameworks are: - OPAL Carto - OPAL crs - OPAL maffinity - OPAL memchecker - OPAL paffinity - ORTE errmgr - ORTE ess - ORTE Filem - ORTE grpcomm - ORTE odls - ORTE pml - ORTE ras - ORTE rmaps - ORTE routed - ORTE snapc - OMPI crcp - OMPI dpm - OMPI pubsub There was a question of the memory footprint change as a result of this commit. I used 'pmap' to determine process memory footprint of a hello world MPI program. Static and Shared build numbers are below along with variations on launching locally and to a single node allocated by SLURM. All of this was on Indiana University's Odin machine. We compare against the trunk (r18276) representing the last SVN sync point of the branch. Process(shared)| Trunk| Branch | Diff (Improvement) ---+--+-+--- mpirun (orted) | 39976K | 36828K | 3148K hello (0) | 229288K | 229268K | 20K hello (1) | 229288K | 229268K | 20K ---+--+-+--- mpirun | 40032K | 37924K | 2108K orted | 34720K | 34660K | 60K hello (0) | 228404K | 228384K | 20K hello (1) | 228404K | 228384K | 20K Process(static)| Trunk| Branch | Diff (Improvement) ---+--+-+--- mpirun (orted) | 21384K | 21372K | 12K hello (0) | 194000K | 193980K | 20K hello (1) | 194000K | 193980K | 20K ---+--+-+--- mpirun | 21384K | 21372K | 12K orted | 21208K | 21196K | 12K hello (0) | 193116K | 193096K | 20K hello (1) | 193116K | 193096K | 20K As you can see there are some small memory footprint improvements on my branch th
Re: [OMPI devel] [RFC] mca_base_select()
Sorry about that. I didn't test that type of option. It should be working in r18418. Let me know if you see any more issues. -- Josh On May 8, 2008, at 6:04 PM, Pak Lui wrote: I think I have a problem but I am not sure. I used to be able to use the circumflex (^) to switch between the gridengine launcher and the ssh launchers by doing something like this, e.g. -mca plm ^gridengine, to exclude some of the components plm (and also in ras). It doesn't seem like the 'negate' is in mca_base_component anymore. I guess I just have to spell out which component I want explicitly... Josh Hursey wrote: This has been committed in r18381 Please let me know if you have any problems with this commit. Cheers, Josh On May 5, 2008, at 10:41 AM, Josh Hursey wrote: Awesome. The branch is updated to the latest trunk head. I encourage folks to check out this repository and make sure that it builds on their system. A normal build of the branch should be enough to find out if there are any cut-n-paste problems (though I tried to be careful, mistakes do happen). I haven't heard any problems so this is looking like it will come in tomorrow after the teleconf. I'll ask again there to see if there are any voices of concern. Cheers, Josh On May 5, 2008, at 9:58 AM, Jeff Squyres wrote: This all sounds good to me! On Apr 29, 2008, at 6:35 PM, Josh Hursey wrote: What: Add mca_base_select() and adjust frameworks & components to use it. Why: Consolidation of code for general goodness. Where: https://svn.open-mpi.org/svn/ompi/tmp-public/jjh-mca-play When: Code ready now. Documentation ready soon. Timeout: May 6, 2008 (After teleconf) [1 week] Discussion: --- For a number of years a few developers have been talking about creating a MCA base component selection function. For various reasons this was never implemented. Recently I decided to give it a try. A base select function will allow Open MPI to provide completely consistent selection behavior for many of its frameworks (18 of 31 to be exact at the moment). The primary goal of this work is to improving code maintainability through code reuse. Other benefits also result such as a slightly smaller memory footprint. The mca_base_select() function represented the most commonly used logic for component selection: Select the one component with the highest priority and close all of the not selected components. This function can be found at the path below in the branch: opal/mca/base/mca_base_components_select.c To support this I had to formalize a query() function in the mca_base_component_t of the form: int mca_base_query_component_fn(mca_base_module_t **module, int *priority); This function is specified after the open and close component functions in this structure as to allow compatibility with frameworks that do not use the base selection logic. Frameworks that do *not* use this function are *not* effected by this commit. However, every component in the frameworks that use the mca_base_select function must adjust their component query function to fit that specified above. 18 frameworks in Open MPI have been changed. I have updated all of the components in the 18 frameworks available in the trunk on my branch. The effected frameworks are: - OPAL Carto - OPAL crs - OPAL maffinity - OPAL memchecker - OPAL paffinity - ORTE errmgr - ORTE ess - ORTE Filem - ORTE grpcomm - ORTE odls - ORTE pml - ORTE ras - ORTE rmaps - ORTE routed - ORTE snapc - OMPI crcp - OMPI dpm - OMPI pubsub There was a question of the memory footprint change as a result of this commit. I used 'pmap' to determine process memory footprint of a hello world MPI program. Static and Shared build numbers are below along with variations on launching locally and to a single node allocated by SLURM. All of this was on Indiana University's Odin machine. We compare against the trunk (r18276) representing the last SVN sync point of the branch. Process(shared)| Trunk| Branch | Diff (Improvement) ---+--+-+--- mpirun (orted) | 39976K | 36828K | 3148K hello (0) | 229288K | 229268K | 20K hello (1) | 229288K | 229268K | 20K ---+--+-+--- mpirun | 40032K | 37924K | 2108K orted | 34720K | 34660K | 60K hello (0) | 228404K | 228384K | 20K hello (1) | 228404K | 228384K | 20K Process(static)| Trunk| Branch | Diff (Improvement) ---+--+-+--- mpirun (orted) | 21384K | 21372K | 12K hello (0) | 194000K | 193980K | 20K hello (1) | 194000K | 193980K | 20K ---+--+-+--- mpirun | 21384K | 21372K | 12K orted | 21208K | 21196K | 12K hello (0) | 193116K | 193096K | 20K hello (1) | 193116K | 193096K | 20K As you can see there are some small memory footprint improvements on my branch that result from this work. The size of the
Re: [OMPI devel] [RFC] mca_base_select()
I think I have a problem but I am not sure. I used to be able to use the circumflex (^) to switch between the gridengine launcher and the ssh launchers by doing something like this, e.g. -mca plm ^gridengine, to exclude some of the components plm (and also in ras). It doesn't seem like the 'negate' is in mca_base_component anymore. I guess I just have to spell out which component I want explicitly... Josh Hursey wrote: This has been committed in r18381 Please let me know if you have any problems with this commit. Cheers, Josh On May 5, 2008, at 10:41 AM, Josh Hursey wrote: Awesome. The branch is updated to the latest trunk head. I encourage folks to check out this repository and make sure that it builds on their system. A normal build of the branch should be enough to find out if there are any cut-n-paste problems (though I tried to be careful, mistakes do happen). I haven't heard any problems so this is looking like it will come in tomorrow after the teleconf. I'll ask again there to see if there are any voices of concern. Cheers, Josh On May 5, 2008, at 9:58 AM, Jeff Squyres wrote: This all sounds good to me! On Apr 29, 2008, at 6:35 PM, Josh Hursey wrote: What: Add mca_base_select() and adjust frameworks & components to use it. Why: Consolidation of code for general goodness. Where: https://svn.open-mpi.org/svn/ompi/tmp-public/jjh-mca-play When: Code ready now. Documentation ready soon. Timeout: May 6, 2008 (After teleconf) [1 week] Discussion: --- For a number of years a few developers have been talking about creating a MCA base component selection function. For various reasons this was never implemented. Recently I decided to give it a try. A base select function will allow Open MPI to provide completely consistent selection behavior for many of its frameworks (18 of 31 to be exact at the moment). The primary goal of this work is to improving code maintainability through code reuse. Other benefits also result such as a slightly smaller memory footprint. The mca_base_select() function represented the most commonly used logic for component selection: Select the one component with the highest priority and close all of the not selected components. This function can be found at the path below in the branch: opal/mca/base/mca_base_components_select.c To support this I had to formalize a query() function in the mca_base_component_t of the form: int mca_base_query_component_fn(mca_base_module_t **module, int *priority); This function is specified after the open and close component functions in this structure as to allow compatibility with frameworks that do not use the base selection logic. Frameworks that do *not* use this function are *not* effected by this commit. However, every component in the frameworks that use the mca_base_select function must adjust their component query function to fit that specified above. 18 frameworks in Open MPI have been changed. I have updated all of the components in the 18 frameworks available in the trunk on my branch. The effected frameworks are: - OPAL Carto - OPAL crs - OPAL maffinity - OPAL memchecker - OPAL paffinity - ORTE errmgr - ORTE ess - ORTE Filem - ORTE grpcomm - ORTE odls - ORTE pml - ORTE ras - ORTE rmaps - ORTE routed - ORTE snapc - OMPI crcp - OMPI dpm - OMPI pubsub There was a question of the memory footprint change as a result of this commit. I used 'pmap' to determine process memory footprint of a hello world MPI program. Static and Shared build numbers are below along with variations on launching locally and to a single node allocated by SLURM. All of this was on Indiana University's Odin machine. We compare against the trunk (r18276) representing the last SVN sync point of the branch. Process(shared)| Trunk| Branch | Diff (Improvement) ---+--+-+--- mpirun (orted) | 39976K | 36828K | 3148K hello (0) | 229288K | 229268K | 20K hello (1) | 229288K | 229268K | 20K ---+--+-+--- mpirun | 40032K | 37924K | 2108K orted | 34720K | 34660K | 60K hello (0) | 228404K | 228384K | 20K hello (1) | 228404K | 228384K | 20K Process(static)| Trunk| Branch | Diff (Improvement) ---+--+-+--- mpirun (orted) | 21384K | 21372K | 12K hello (0) | 194000K | 193980K | 20K hello (1) | 194000K | 193980K | 20K ---+--+-+--- mpirun | 21384K | 21372K | 12K orted | 21208K | 21196K | 12K hello (0) | 193116K | 193096K | 20K hello (1) | 193116K | 193096K | 20K As you can see there are some small memory footprint improvements on my branch that result from this work. The size of the Open MPI project shrinks a bit as well. This commit cuts between 3,500 and 2,000 lines of code (depending on how you count) so about a ~1% code shrink. The branch is stable in all of th
Re: [OMPI devel] [RFC] mca_base_select()
Excellent! Thanks Josh - both for the original work/commit and for the quick fix! Ralph On 5/6/08 3:58 PM, "Josh Hursey" wrote: > Sorry about that. Looking back at the filem logic it seems that I > returned success even if select failed (and just use the 'none' > passthrough component). I committed a patch in r18389 that fixes this > problem. > > This commit now has a warning that prints on the filem verbose stream > so if a user hits something like this in the wild unexpectedly then > we can help them debug it a bit. > > Cheers, > Josh > > > On May 6, 2008, at 2:56 PM, Ralph H Castain wrote: > >> Hmmmwell, I hit a problem (of course!). I have mca-no-build on >> the filem >> framework on my Mac. If I just mpriun -n 3 ./hello, I get the >> following >> error: >> >> -- >> >> It looks like orte_init failed for some reason; your parallel >> process is >> likely to abort. There are many reasons that a parallel process can >> fail during orte_init; some of which are due to configuration or >> environment problems. This failure appears to be an internal failure; >> here's some additional information (which may only be relevant to an >> Open MPI developer): >> >> orte_filem_base_select failed >> --> Returned value Error (-1) instead of ORTE_SUCCESS >> >> -- >> >> >> After looking at the source code for filem_select, I can run just >> fine if I >> specify -mca filem none on the cmd line. Otherwise, it looks like your >> select logic insists that at least one component must be built and >> selectable? >> >> Is that generally true, or is your filem framework the exception? I >> think >> this would not be a good general requirement - frankly, I don't >> think it is >> good for any framework to have such a requirement. >> >> Ralph >> >> >> >> On 5/6/08 12:09 PM, "Josh Hursey" wrote: >> >>> This has been committed in r18381 >>> >>> Please let me know if you have any problems with this commit. >>> >>> Cheers, >>> Josh >>> >>> On May 5, 2008, at 10:41 AM, Josh Hursey wrote: >>> Awesome. The branch is updated to the latest trunk head. I encourage folks to check out this repository and make sure that it builds on their system. A normal build of the branch should be enough to find out if there are any cut-n-paste problems (though I tried to be careful, mistakes do happen). I haven't heard any problems so this is looking like it will come in tomorrow after the teleconf. I'll ask again there to see if there are any voices of concern. Cheers, Josh On May 5, 2008, at 9:58 AM, Jeff Squyres wrote: > This all sounds good to me! > > On Apr 29, 2008, at 6:35 PM, Josh Hursey wrote: > >> What: Add mca_base_select() and adjust frameworks & components to >> use >> it. >> Why: Consolidation of code for general goodness. >> Where: https://svn.open-mpi.org/svn/ompi/tmp-public/jjh-mca-play >> When: Code ready now. Documentation ready soon. >> Timeout: May 6, 2008 (After teleconf) [1 week] >> >> Discussion: >> --- >> For a number of years a few developers have been talking about >> creating a MCA base component selection function. For various >> reasons >> this was never implemented. Recently I decided to give it a try. >> >> A base select function will allow Open MPI to provide completely >> consistent selection behavior for many of its frameworks (18 of 31 >> to >> be exact at the moment). The primary goal of this work is to >> improving >> code maintainability through code reuse. Other benefits also >> result >> such as a slightly smaller memory footprint. >> >> The mca_base_select() function represented the most commonly used >> logic for component selection: Select the one component with the >> highest priority and close all of the not selected components. >> This >> function can be found at the path below in the branch: >> opal/mca/base/mca_base_components_select.c >> >> To support this I had to formalize a query() function in the >> mca_base_component_t of the form: >> int mca_base_query_component_fn(mca_base_module_t **module, int >> *priority); >> >> This function is specified after the open and close component >> functions in this structure as to allow compatibility with >> frameworks >> that do not use the base selection logic. Frameworks that do *not* >> use >> this function are *not* effected by this commit. However, every >> component in the frameworks that use the mca_base_select function >> must >> adjust their component query function to fit that specified above. >> >> 18 frameworks in Open MPI have been changed. I have updated all of
Re: [OMPI devel] [RFC] mca_base_select()
Sorry about that. Looking back at the filem logic it seems that I returned success even if select failed (and just use the 'none' passthrough component). I committed a patch in r18389 that fixes this problem. This commit now has a warning that prints on the filem verbose stream so if a user hits something like this in the wild unexpectedly then we can help them debug it a bit. Cheers, Josh On May 6, 2008, at 2:56 PM, Ralph H Castain wrote: Hmmmwell, I hit a problem (of course!). I have mca-no-build on the filem framework on my Mac. If I just mpriun -n 3 ./hello, I get the following error: -- It looks like orte_init failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during orte_init; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer): orte_filem_base_select failed --> Returned value Error (-1) instead of ORTE_SUCCESS -- After looking at the source code for filem_select, I can run just fine if I specify -mca filem none on the cmd line. Otherwise, it looks like your select logic insists that at least one component must be built and selectable? Is that generally true, or is your filem framework the exception? I think this would not be a good general requirement - frankly, I don't think it is good for any framework to have such a requirement. Ralph On 5/6/08 12:09 PM, "Josh Hursey" wrote: This has been committed in r18381 Please let me know if you have any problems with this commit. Cheers, Josh On May 5, 2008, at 10:41 AM, Josh Hursey wrote: Awesome. The branch is updated to the latest trunk head. I encourage folks to check out this repository and make sure that it builds on their system. A normal build of the branch should be enough to find out if there are any cut-n-paste problems (though I tried to be careful, mistakes do happen). I haven't heard any problems so this is looking like it will come in tomorrow after the teleconf. I'll ask again there to see if there are any voices of concern. Cheers, Josh On May 5, 2008, at 9:58 AM, Jeff Squyres wrote: This all sounds good to me! On Apr 29, 2008, at 6:35 PM, Josh Hursey wrote: What: Add mca_base_select() and adjust frameworks & components to use it. Why: Consolidation of code for general goodness. Where: https://svn.open-mpi.org/svn/ompi/tmp-public/jjh-mca-play When: Code ready now. Documentation ready soon. Timeout: May 6, 2008 (After teleconf) [1 week] Discussion: --- For a number of years a few developers have been talking about creating a MCA base component selection function. For various reasons this was never implemented. Recently I decided to give it a try. A base select function will allow Open MPI to provide completely consistent selection behavior for many of its frameworks (18 of 31 to be exact at the moment). The primary goal of this work is to improving code maintainability through code reuse. Other benefits also result such as a slightly smaller memory footprint. The mca_base_select() function represented the most commonly used logic for component selection: Select the one component with the highest priority and close all of the not selected components. This function can be found at the path below in the branch: opal/mca/base/mca_base_components_select.c To support this I had to formalize a query() function in the mca_base_component_t of the form: int mca_base_query_component_fn(mca_base_module_t **module, int *priority); This function is specified after the open and close component functions in this structure as to allow compatibility with frameworks that do not use the base selection logic. Frameworks that do *not* use this function are *not* effected by this commit. However, every component in the frameworks that use the mca_base_select function must adjust their component query function to fit that specified above. 18 frameworks in Open MPI have been changed. I have updated all of the components in the 18 frameworks available in the trunk on my branch. The effected frameworks are: - OPAL Carto - OPAL crs - OPAL maffinity - OPAL memchecker - OPAL paffinity - ORTE errmgr - ORTE ess - ORTE Filem - ORTE grpcomm - ORTE odls - ORTE pml - ORTE ras - ORTE rmaps - ORTE routed - ORTE snapc - OMPI crcp - OMPI dpm - OMPI pubsub There was a question of the memory footprint change as a result of this commit. I used 'pmap' to determine process memory footprint of a hello world MPI program. Static and Shared build numbers are below along with variations on launching locally and to a single node allocated by SLURM. All of this was on Indiana University's Odin machine. We compare against the trunk (
Re: [OMPI devel] [RFC] mca_base_select()
Hmmmwell, I hit a problem (of course!). I have mca-no-build on the filem framework on my Mac. If I just mpriun -n 3 ./hello, I get the following error: -- It looks like orte_init failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during orte_init; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer): orte_filem_base_select failed --> Returned value Error (-1) instead of ORTE_SUCCESS -- After looking at the source code for filem_select, I can run just fine if I specify -mca filem none on the cmd line. Otherwise, it looks like your select logic insists that at least one component must be built and selectable? Is that generally true, or is your filem framework the exception? I think this would not be a good general requirement - frankly, I don't think it is good for any framework to have such a requirement. Ralph On 5/6/08 12:09 PM, "Josh Hursey" wrote: > This has been committed in r18381 > > Please let me know if you have any problems with this commit. > > Cheers, > Josh > > On May 5, 2008, at 10:41 AM, Josh Hursey wrote: > >> Awesome. >> >> The branch is updated to the latest trunk head. I encourage folks to >> check out this repository and make sure that it builds on their >> system. A normal build of the branch should be enough to find out if >> there are any cut-n-paste problems (though I tried to be careful, >> mistakes do happen). >> >> I haven't heard any problems so this is looking like it will come in >> tomorrow after the teleconf. I'll ask again there to see if there are >> any voices of concern. >> >> Cheers, >> Josh >> >> On May 5, 2008, at 9:58 AM, Jeff Squyres wrote: >> >>> This all sounds good to me! >>> >>> On Apr 29, 2008, at 6:35 PM, Josh Hursey wrote: >>> What: Add mca_base_select() and adjust frameworks & components to use it. Why: Consolidation of code for general goodness. Where: https://svn.open-mpi.org/svn/ompi/tmp-public/jjh-mca-play When: Code ready now. Documentation ready soon. Timeout: May 6, 2008 (After teleconf) [1 week] Discussion: --- For a number of years a few developers have been talking about creating a MCA base component selection function. For various reasons this was never implemented. Recently I decided to give it a try. A base select function will allow Open MPI to provide completely consistent selection behavior for many of its frameworks (18 of 31 to be exact at the moment). The primary goal of this work is to improving code maintainability through code reuse. Other benefits also result such as a slightly smaller memory footprint. The mca_base_select() function represented the most commonly used logic for component selection: Select the one component with the highest priority and close all of the not selected components. This function can be found at the path below in the branch: opal/mca/base/mca_base_components_select.c To support this I had to formalize a query() function in the mca_base_component_t of the form: int mca_base_query_component_fn(mca_base_module_t **module, int *priority); This function is specified after the open and close component functions in this structure as to allow compatibility with frameworks that do not use the base selection logic. Frameworks that do *not* use this function are *not* effected by this commit. However, every component in the frameworks that use the mca_base_select function must adjust their component query function to fit that specified above. 18 frameworks in Open MPI have been changed. I have updated all of the components in the 18 frameworks available in the trunk on my branch. The effected frameworks are: - OPAL Carto - OPAL crs - OPAL maffinity - OPAL memchecker - OPAL paffinity - ORTE errmgr - ORTE ess - ORTE Filem - ORTE grpcomm - ORTE odls - ORTE pml - ORTE ras - ORTE rmaps - ORTE routed - ORTE snapc - OMPI crcp - OMPI dpm - OMPI pubsub There was a question of the memory footprint change as a result of this commit. I used 'pmap' to determine process memory footprint of a hello world MPI program. Static and Shared build numbers are below along with variations on launching locally and to a single node allocated by SLURM. All of this was on Indiana University's Odin machine. We compare against the trunk (r18276) representing the last SVN sync
Re: [OMPI devel] [RFC] mca_base_select()
This has been committed in r18381 Please let me know if you have any problems with this commit. Cheers, Josh On May 5, 2008, at 10:41 AM, Josh Hursey wrote: Awesome. The branch is updated to the latest trunk head. I encourage folks to check out this repository and make sure that it builds on their system. A normal build of the branch should be enough to find out if there are any cut-n-paste problems (though I tried to be careful, mistakes do happen). I haven't heard any problems so this is looking like it will come in tomorrow after the teleconf. I'll ask again there to see if there are any voices of concern. Cheers, Josh On May 5, 2008, at 9:58 AM, Jeff Squyres wrote: This all sounds good to me! On Apr 29, 2008, at 6:35 PM, Josh Hursey wrote: What: Add mca_base_select() and adjust frameworks & components to use it. Why: Consolidation of code for general goodness. Where: https://svn.open-mpi.org/svn/ompi/tmp-public/jjh-mca-play When: Code ready now. Documentation ready soon. Timeout: May 6, 2008 (After teleconf) [1 week] Discussion: --- For a number of years a few developers have been talking about creating a MCA base component selection function. For various reasons this was never implemented. Recently I decided to give it a try. A base select function will allow Open MPI to provide completely consistent selection behavior for many of its frameworks (18 of 31 to be exact at the moment). The primary goal of this work is to improving code maintainability through code reuse. Other benefits also result such as a slightly smaller memory footprint. The mca_base_select() function represented the most commonly used logic for component selection: Select the one component with the highest priority and close all of the not selected components. This function can be found at the path below in the branch: opal/mca/base/mca_base_components_select.c To support this I had to formalize a query() function in the mca_base_component_t of the form: int mca_base_query_component_fn(mca_base_module_t **module, int *priority); This function is specified after the open and close component functions in this structure as to allow compatibility with frameworks that do not use the base selection logic. Frameworks that do *not* use this function are *not* effected by this commit. However, every component in the frameworks that use the mca_base_select function must adjust their component query function to fit that specified above. 18 frameworks in Open MPI have been changed. I have updated all of the components in the 18 frameworks available in the trunk on my branch. The effected frameworks are: - OPAL Carto - OPAL crs - OPAL maffinity - OPAL memchecker - OPAL paffinity - ORTE errmgr - ORTE ess - ORTE Filem - ORTE grpcomm - ORTE odls - ORTE pml - ORTE ras - ORTE rmaps - ORTE routed - ORTE snapc - OMPI crcp - OMPI dpm - OMPI pubsub There was a question of the memory footprint change as a result of this commit. I used 'pmap' to determine process memory footprint of a hello world MPI program. Static and Shared build numbers are below along with variations on launching locally and to a single node allocated by SLURM. All of this was on Indiana University's Odin machine. We compare against the trunk (r18276) representing the last SVN sync point of the branch. Process(shared)| Trunk| Branch | Diff (Improvement) ---+--+-+--- mpirun (orted) | 39976K | 36828K | 3148K hello (0) | 229288K | 229268K | 20K hello (1) | 229288K | 229268K | 20K ---+--+-+--- mpirun | 40032K | 37924K | 2108K orted | 34720K | 34660K | 60K hello (0) | 228404K | 228384K | 20K hello (1) | 228404K | 228384K | 20K Process(static)| Trunk| Branch | Diff (Improvement) ---+--+-+--- mpirun (orted) | 21384K | 21372K | 12K hello (0) | 194000K | 193980K | 20K hello (1) | 194000K | 193980K | 20K ---+--+-+--- mpirun | 21384K | 21372K | 12K orted | 21208K | 21196K | 12K hello (0) | 193116K | 193096K | 20K hello (1) | 193116K | 193096K | 20K As you can see there are some small memory footprint improvements on my branch that result from this work. The size of the Open MPI project shrinks a bit as well. This commit cuts between 3,500 and 2,000 lines of code (depending on how you count) so about a ~1% code shrink. The branch is stable in all of the testing I have done, but there are some platforms on which I cannot test. So please give this branch a try and let me know if you find any problems. Cheers, Josh ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco Systems ___ devel mailing list de...@open-mpi.org http:
Re: [OMPI devel] [RFC] mca_base_select()
Awesome. The branch is updated to the latest trunk head. I encourage folks to check out this repository and make sure that it builds on their system. A normal build of the branch should be enough to find out if there are any cut-n-paste problems (though I tried to be careful, mistakes do happen). I haven't heard any problems so this is looking like it will come in tomorrow after the teleconf. I'll ask again there to see if there are any voices of concern. Cheers, Josh On May 5, 2008, at 9:58 AM, Jeff Squyres wrote: This all sounds good to me! On Apr 29, 2008, at 6:35 PM, Josh Hursey wrote: What: Add mca_base_select() and adjust frameworks & components to use it. Why: Consolidation of code for general goodness. Where: https://svn.open-mpi.org/svn/ompi/tmp-public/jjh-mca-play When: Code ready now. Documentation ready soon. Timeout: May 6, 2008 (After teleconf) [1 week] Discussion: --- For a number of years a few developers have been talking about creating a MCA base component selection function. For various reasons this was never implemented. Recently I decided to give it a try. A base select function will allow Open MPI to provide completely consistent selection behavior for many of its frameworks (18 of 31 to be exact at the moment). The primary goal of this work is to improving code maintainability through code reuse. Other benefits also result such as a slightly smaller memory footprint. The mca_base_select() function represented the most commonly used logic for component selection: Select the one component with the highest priority and close all of the not selected components. This function can be found at the path below in the branch: opal/mca/base/mca_base_components_select.c To support this I had to formalize a query() function in the mca_base_component_t of the form: int mca_base_query_component_fn(mca_base_module_t **module, int *priority); This function is specified after the open and close component functions in this structure as to allow compatibility with frameworks that do not use the base selection logic. Frameworks that do *not* use this function are *not* effected by this commit. However, every component in the frameworks that use the mca_base_select function must adjust their component query function to fit that specified above. 18 frameworks in Open MPI have been changed. I have updated all of the components in the 18 frameworks available in the trunk on my branch. The effected frameworks are: - OPAL Carto - OPAL crs - OPAL maffinity - OPAL memchecker - OPAL paffinity - ORTE errmgr - ORTE ess - ORTE Filem - ORTE grpcomm - ORTE odls - ORTE pml - ORTE ras - ORTE rmaps - ORTE routed - ORTE snapc - OMPI crcp - OMPI dpm - OMPI pubsub There was a question of the memory footprint change as a result of this commit. I used 'pmap' to determine process memory footprint of a hello world MPI program. Static and Shared build numbers are below along with variations on launching locally and to a single node allocated by SLURM. All of this was on Indiana University's Odin machine. We compare against the trunk (r18276) representing the last SVN sync point of the branch. Process(shared)| Trunk| Branch | Diff (Improvement) ---+--+-+--- mpirun (orted) | 39976K | 36828K | 3148K hello (0) | 229288K | 229268K | 20K hello (1) | 229288K | 229268K | 20K ---+--+-+--- mpirun | 40032K | 37924K | 2108K orted | 34720K | 34660K | 60K hello (0) | 228404K | 228384K | 20K hello (1) | 228404K | 228384K | 20K Process(static)| Trunk| Branch | Diff (Improvement) ---+--+-+--- mpirun (orted) | 21384K | 21372K | 12K hello (0) | 194000K | 193980K | 20K hello (1) | 194000K | 193980K | 20K ---+--+-+--- mpirun | 21384K | 21372K | 12K orted | 21208K | 21196K | 12K hello (0) | 193116K | 193096K | 20K hello (1) | 193116K | 193096K | 20K As you can see there are some small memory footprint improvements on my branch that result from this work. The size of the Open MPI project shrinks a bit as well. This commit cuts between 3,500 and 2,000 lines of code (depending on how you count) so about a ~1% code shrink. The branch is stable in all of the testing I have done, but there are some platforms on which I cannot test. So please give this branch a try and let me know if you find any problems. Cheers, Josh ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco Systems ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] [RFC] mca_base_select()
This all sounds good to me! On Apr 29, 2008, at 6:35 PM, Josh Hursey wrote: What: Add mca_base_select() and adjust frameworks & components to use it. Why: Consolidation of code for general goodness. Where: https://svn.open-mpi.org/svn/ompi/tmp-public/jjh-mca-play When: Code ready now. Documentation ready soon. Timeout: May 6, 2008 (After teleconf) [1 week] Discussion: --- For a number of years a few developers have been talking about creating a MCA base component selection function. For various reasons this was never implemented. Recently I decided to give it a try. A base select function will allow Open MPI to provide completely consistent selection behavior for many of its frameworks (18 of 31 to be exact at the moment). The primary goal of this work is to improving code maintainability through code reuse. Other benefits also result such as a slightly smaller memory footprint. The mca_base_select() function represented the most commonly used logic for component selection: Select the one component with the highest priority and close all of the not selected components. This function can be found at the path below in the branch: opal/mca/base/mca_base_components_select.c To support this I had to formalize a query() function in the mca_base_component_t of the form: int mca_base_query_component_fn(mca_base_module_t **module, int *priority); This function is specified after the open and close component functions in this structure as to allow compatibility with frameworks that do not use the base selection logic. Frameworks that do *not* use this function are *not* effected by this commit. However, every component in the frameworks that use the mca_base_select function must adjust their component query function to fit that specified above. 18 frameworks in Open MPI have been changed. I have updated all of the components in the 18 frameworks available in the trunk on my branch. The effected frameworks are: - OPAL Carto - OPAL crs - OPAL maffinity - OPAL memchecker - OPAL paffinity - ORTE errmgr - ORTE ess - ORTE Filem - ORTE grpcomm - ORTE odls - ORTE pml - ORTE ras - ORTE rmaps - ORTE routed - ORTE snapc - OMPI crcp - OMPI dpm - OMPI pubsub There was a question of the memory footprint change as a result of this commit. I used 'pmap' to determine process memory footprint of a hello world MPI program. Static and Shared build numbers are below along with variations on launching locally and to a single node allocated by SLURM. All of this was on Indiana University's Odin machine. We compare against the trunk (r18276) representing the last SVN sync point of the branch. Process(shared)| Trunk| Branch | Diff (Improvement) ---+--+-+--- mpirun (orted) | 39976K | 36828K | 3148K hello (0) | 229288K | 229268K | 20K hello (1) | 229288K | 229268K | 20K ---+--+-+--- mpirun | 40032K | 37924K | 2108K orted | 34720K | 34660K | 60K hello (0) | 228404K | 228384K | 20K hello (1) | 228404K | 228384K | 20K Process(static)| Trunk| Branch | Diff (Improvement) ---+--+-+--- mpirun (orted) | 21384K | 21372K | 12K hello (0) | 194000K | 193980K | 20K hello (1) | 194000K | 193980K | 20K ---+--+-+--- mpirun | 21384K | 21372K | 12K orted | 21208K | 21196K | 12K hello (0) | 193116K | 193096K | 20K hello (1) | 193116K | 193096K | 20K As you can see there are some small memory footprint improvements on my branch that result from this work. The size of the Open MPI project shrinks a bit as well. This commit cuts between 3,500 and 2,000 lines of code (depending on how you count) so about a ~1% code shrink. The branch is stable in all of the testing I have done, but there are some platforms on which I cannot test. So please give this branch a try and let me know if you find any problems. Cheers, Josh ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco Systems
[OMPI devel] [RFC] mca_base_select()
What: Add mca_base_select() and adjust frameworks & components to use it. Why: Consolidation of code for general goodness. Where: https://svn.open-mpi.org/svn/ompi/tmp-public/jjh-mca-play When: Code ready now. Documentation ready soon. Timeout: May 6, 2008 (After teleconf) [1 week] Discussion: --- For a number of years a few developers have been talking about creating a MCA base component selection function. For various reasons this was never implemented. Recently I decided to give it a try. A base select function will allow Open MPI to provide completely consistent selection behavior for many of its frameworks (18 of 31 to be exact at the moment). The primary goal of this work is to improving code maintainability through code reuse. Other benefits also result such as a slightly smaller memory footprint. The mca_base_select() function represented the most commonly used logic for component selection: Select the one component with the highest priority and close all of the not selected components. This function can be found at the path below in the branch: opal/mca/base/mca_base_components_select.c To support this I had to formalize a query() function in the mca_base_component_t of the form: int mca_base_query_component_fn(mca_base_module_t **module, int *priority); This function is specified after the open and close component functions in this structure as to allow compatibility with frameworks that do not use the base selection logic. Frameworks that do *not* use this function are *not* effected by this commit. However, every component in the frameworks that use the mca_base_select function must adjust their component query function to fit that specified above. 18 frameworks in Open MPI have been changed. I have updated all of the components in the 18 frameworks available in the trunk on my branch. The effected frameworks are: - OPAL Carto - OPAL crs - OPAL maffinity - OPAL memchecker - OPAL paffinity - ORTE errmgr - ORTE ess - ORTE Filem - ORTE grpcomm - ORTE odls - ORTE pml - ORTE ras - ORTE rmaps - ORTE routed - ORTE snapc - OMPI crcp - OMPI dpm - OMPI pubsub There was a question of the memory footprint change as a result of this commit. I used 'pmap' to determine process memory footprint of a hello world MPI program. Static and Shared build numbers are below along with variations on launching locally and to a single node allocated by SLURM. All of this was on Indiana University's Odin machine. We compare against the trunk (r18276) representing the last SVN sync point of the branch. Process(shared)| Trunk| Branch | Diff (Improvement) ---+--+-+--- mpirun (orted) | 39976K | 36828K | 3148K hello (0) | 229288K | 229268K | 20K hello (1) | 229288K | 229268K | 20K ---+--+-+--- mpirun | 40032K | 37924K | 2108K orted | 34720K | 34660K | 60K hello (0) | 228404K | 228384K | 20K hello (1) | 228404K | 228384K | 20K Process(static)| Trunk| Branch | Diff (Improvement) ---+--+-+--- mpirun (orted) | 21384K | 21372K | 12K hello (0) | 194000K | 193980K | 20K hello (1) | 194000K | 193980K | 20K ---+--+-+--- mpirun | 21384K | 21372K | 12K orted | 21208K | 21196K | 12K hello (0) | 193116K | 193096K | 20K hello (1) | 193116K | 193096K | 20K As you can see there are some small memory footprint improvements on my branch that result from this work. The size of the Open MPI project shrinks a bit as well. This commit cuts between 3,500 and 2,000 lines of code (depending on how you count) so about a ~1% code shrink. The branch is stable in all of the testing I have done, but there are some platforms on which I cannot test. So please give this branch a try and let me know if you find any problems. Cheers, Josh
