Thank you for your comment, Ralph.
I understand your explanation including "it's too late".
The ppr option is convinient for us because our environment is quite
hetero.
(It gives flexiblity to the number of procs)
I hope you do not deprecate ppr in the future release and aply my proposal
someday.
Regards,
Tetsuya Mishima
> I'm afraid it is too late for 1.7.4 as I have locked that down, barring
any last-second smoke test failures. I'll give this some thought for 1.7.5,
but I'm a little leery of the proposed change. The
> problem is that ppr comes in thru a different MCA param than the "map-by"
param, and hence we can indeed get conflicts that we cannot resolve.
>
> This is one of those issues that I need to cleanup in general. We've
deprecated a number of params due to similar problems - the "ppr" policy is
the last one on the list. Needs to somehow be folded
> into the "map-by" param, though it also influences the number of procs
(unlike the other map-by directives).
>
>
> On Jan 27, 2014, at 7:46 PM, tmish...@jcity.maeda.co.jp wrote:
>
> >
> >
> > Hi Ralph, it seems you are rounding the final turn to release 1.7.4!
> > I hope this will be my final request for openmpi-1.7.4 as well.
> >
> > I mostly use rr_mapper but sometimes use ppr_mapper. I have a simple
> > request to ask you to improve its usability. Namely, I propose to
> > remove redfining-policy-check routine in rmaps_ppr_component.c
> > (the line 130-138) :
> >
> > 130 if (ORTE_MAPPING_GIVEN & ORTE_GET_MAPPING_DIRECTIVE
> > (orte_rmaps_base.mapping)) {
> > 131 /* if a non-default mapping is already specified, then
we
> > 132 * have an error
> > 133 */
> > 134 orte_show_help("help-orte-rmaps-base.txt",
> > "redefining-policy", true, "mapping",
> > 135 "PPR", orte_rmaps_base_print_mapping
> > (orte_rmaps_base.mapping));
> > 136 ORTE_SET_MAPPING_DIRECTIVE(orte_rmaps_base.mapping,
> > ORTE_MAPPING_CONFLICTED);
> > 137 return ORTE_ERR_SILENT;
> > 138 }
> >
> > The reasons are as follows:
> >
> > 1) The final mapper to be used should be selected by the priority set
> > by system or mca param. The ppr_priority is fixed to be 90 and the
> > rr_priority can be set by mca param(default = 10).
> >
> > 2) If we set "rmaps_base_mapping_policy = something" in
> > mca-params.conf, -ppr option is always refused by this check as
> > below:
> > [mishima@manage demos]$ mpirun -np 2 -ppr 1:socket
> > ~/mis/openmpi/demos/myprog
> >
--------------------------------------------------------------------------
> > Conflicting directives for mapping policy are causing the policy
> > to be redefined:
> >
> > New policy: PPR
> > Prior policy: BYSOCKET
> >
> > Please check that only one policy is defined.
> >
> > 3) This fix does not seem to affect any other behavior as far as
> > I confirmed.
> >
> > Regard,
> > Tetsuya Mishima
> >
> >> Kewl - thanks!
> >>
> >> On Jan 27, 2014, at 4:08 PM, tmish...@jcity.maeda.co.jp wrote:
> >>
> >>>
> >>>
> >>> Thanks, Ralph. I quickly checked the fix. It worked fine for me.
> >>>
> >>> Tetsuya Mishima
> >>>
> >>>> I fixed that in today's final cleanup
> >>>>
> >>>> On Jan 27, 2014, at 3:17 PM, tmish...@jcity.maeda.co.jp wrote:
> >>>>
> >>>>
> >>>>
> >>>> As for the NEWS - it is actually already correct. We default to
map-by
> >>>> core, not slot, as of 1.7.4.
> >>>>
> >>>> Is it correct? As far as I browse the source code, map-by slot is
used
> > if
> >>>> np <=2.
> >>>>
> >>>> [mishima@manage openmpi-1.7.4rc2r30425]$ cat -n
> >>>> orte/mca/rmaps/base/rmaps_base_map_job.c
> >>>> ...
> >>>> 107 /* default based on number of procs */
> >>>> 108 if (nprocs <= 2) {
> >>>> 109 opal_output_verbose(5,
> >>>> orte_rmaps_base_framework.framework_output,
> >>>> 110 "mca:rmaps mapping not
> > given -
> >>>> using byslot");
> >>>> 111 ORTE_SET_MAPPING_POLICY(map->mapping,
> >>>> ORTE_MAPPING_BYSLOT);
> >>>> 112 } else {
> >>>> 113 opal_output_verbose(5,
> >>>> orte_rmaps_base_framework.framework_output,
> >>>> 114 "mca:rmaps mapping not
> > given -
> >>>> using bysocket");
> >>>> 115 ORTE_SET_MAPPING_POLICY(map->mapping,
> >>>> ORTE_MAPPING_BYSOCKET);
> >>>> 116 }
> >>>>
> >>>> Regards,
> >>>> Tetsuya Mishima
> >>>>
> >>>> On Jan 26, 2014, at 3:02 PM, tmish...@jcity.maeda.co.jp wrote:
> >>>>
> >>>>
> >>>> Hi Ralph,
> >>>>
> >>>> I tried latest nightly snapshots of openmpi-1.7.4rc2r30425.tar.gz.
> >>>> Almost everything works fine, except that the unexpected output
> > appears
> >>>> as below:
> >>>>
> >>>> [mishima@node04 ~]$ mpirun -cpus-per-proc 4
~/mis/openmpi/demos/myprog
> >>>> App launch reported: 3 (out of 3) daemons - 8 (out of 12) procs
> >>>> ...
> >>>>
> >>>> You dropped the if-statement checking "orte_report_launch_progress"
in
> >>>> plm_base_receive.c @ r30423, which causes the problem.
> >>>>
> >>>> --- orte/mca/plm/base/plm_base_receive.c.org2014-01-25
> >>>> 11:51:59.000000000 +0900
> >>>> +++ orte/mca/plm/base/plm_base_receive.c2014-01-26
> >>>> 12:20:10.000000000
> >>>> +0900
> >>>> @@ -315,9 +315,11 @@
> >>>> /* record that we heard back from a daemon during app
> >>>> launch
> >>>> */
> >>>> if (running && NULL != jdata) {
> >>>> jdata->num_daemons_reported++;
> >>>> - if (0 == jdata->num_daemons_reported % 100 ||
> >>>> - jdata->num_daemons_reported ==
> >>>> orte_process_info.num_procs) {
> >>>> - ORTE_ACTIVATE_JOB_STATE(jdata,
> >>>> ORTE_JOB_STATE_REPORT_PROGRESS);
> >>>> + if (orte_report_launch_progress) {
> >>>> + if (0 == jdata->num_daemons_reported % 100 ||
> >>>> + jdata->num_daemons_reported ==
> >>>> orte_process_info.num_procs) {
> >>>> + ORTE_ACTIVATE_JOB_STATE(jdata,
> >>>> ORTE_JOB_STATE_REPORT_PROGRESS);
> >>>> + }
> >>>> }
> >>>> }
> >>>> /* prepare for next job */
> >>>>
> >>>> Regards,
> >>>> Tetsuya Mishima
> >>>>
> >>>> P.S. It's also better to change the line 65 in NEWS.
> >>>>
> >>>> ...
> >>>> 64 * Mapping:
> >>>> 65 * if #procs <= 2, default to map-by core -> map-by slot
> >>>> ^^^^^^^^^^^
> >>>> 66 * if #procs > 2, default to map-by socket
> >>>> ...
> >>>>
> >>>> _______________________________________________
> >>>> users mailing list
> >>>> us...@open-mpi.org
> >>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
> >>>>
> >>>> _______________________________________________
> >>>> users mailing list
> >>>> us...@open-mpi.org
> >>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
> >>>>
> >>>> _______________________________________________
> >>>> users mailing list
> >>>> us...@open-mpi.org
> >>>>
> >>>
> >
http://www.open-mpi.org/mailman/listinfo.cgi/users_______________________________________________
> >
> >>>
> >>>> users mailing list
> >>>> users@open-mpi.orghttp://www.open-mpi.org/mailman/listinfo.cgi/users
> >>>
> >>> _______________________________________________
> >>> users mailing list
> >>> us...@open-mpi.org
> >>> http://www.open-mpi.org/mailman/listinfo.cgi/users
> >>
> >> _______________________________________________
> >> users mailing list
> >> us...@open-mpi.org
> >> http://www.open-mpi.org/mailman/listinfo.cgi/users
> >
> > _______________________________________________
> > users mailing list
> > us...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/users
>
> _______________________________________________
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
