As I understood our original discussions, this would move responsibility for
mapping rank to processor back into the orted - is that still true?
Reason I ask is to again clarify for people if we are doing so as it (a)
impacts those systems that don't use our orteds (e.g., will affinity still
work in those environments?); and (b) it will make elimination of the orteds
just a little more difficult.
So could you please clarify for everyone what this code functionally does?
All 1023 does is layout syntax - it doesn't clearly state what happens
On 7/10/07 7:32 AM, "Sharon Melamed" <sharonm_at_[hidden]> wrote:
> Hello All,
> In the recent few weeks I implemented ticket 1023
> <https://svn.open-mpi.org/trac/ompi/ticket/1023> ).
> In a few words, the purpose of ticket 1023 is to expand the hostfile syntax to
> precisely specify slot
> location (in terms of virtual CPU ID or socket core notation) in the node
> and/or rank in a MCW.
> The code is in a temporary branch
> The changes are:
> 1. In the RAS base component:
> a. Added new list of orte_ras_proc_t structures
> b. Each orte_ras_proc_t structure contains 3 members: node_name, rank and
> c. the cpu_list is a string representing the slot list from the hostfile
> i.e.: if the
> SLOT token in the hostfile is - SLOT=1_at_2:1,3:1-4, the slot_list string
> is: 2:1,3:7-9.
> 2. In the RDS hostfile component:
> a. Added new token SLOT to the lex parser.
> b. filling the orte_ras_proc_t structure list according the SLOT token in
> the hostfile.
> 3. In the RMAPS round robin component:
> a. Added new member to orte_mapped_node_t structure - slot_list (similar to
> the slot_list
> in the orte_ras_proc_t structure)
> b. in the orte_rmaps_rr_map, mapping job according to hostfile ranks before
> mapping the job
> by slot or by node.
> c. in the orte_rmaps_rr_map, arranging the MCW ranks according to the
> 4. in the ODLS default module:
> a. Added slot_list to orte_odls_default_get_add_procs_data.
> b. Added slot_list to orte_odls_default_launch_local_procs.
> c. Added new member to the child structure a cpu_set bitmap (for PLPA)
> d. Added mapping of the slot_list string to a cpu_set bitmap in the child
> For more details you can browse the code.
> I would like to merge these changes to the trunk as soon as possible since, as
> I understood from Ralph Castain emails,
> The Open RTE will go through a lot of changes in the near future and since
> this is a relatively small change I want to merge
> it before the big change.
> Any comments?
> devel mailing list