Appropriate mapper components will be used, along with a file
describing which nodes are in which CU etc. So it won't be so much a
matter of discovery as pre-knowledge.
On Jan 21, 2009, at 12:02 PM, Jeff Squyres wrote:
Sounds reasonable. How do you plan to discover this information?
On Jan 21, 2009, at 9:58 AM, Ralph Castain wrote:
What: Extend the current use of the ompi_proc_t flags field
(without changing the field itself)
Why: Provide more atomistic sense of locality to support new
collective/BTL components
Where: Add macros to define and check the various flag fields in
ompi/proc.h. Revise the orte_ess.proc_is_local API to return a
uint8_t instead of bool.
When: For OMPI v1.4
Timeout: COB Fri, Feb 6, 2009
====================================
The current ompi_proc_t structure has a uint8_t flags field in it.
Only one bit of this field is currently used to flag that a proc is
"local". In the current context, "local" is constrained to mean
"local to this node".
New collectives and BTL components under development by LANL (in
partnership with others) require a greater degree of granularity on
the term "local". For our work, we need to know if the proc is on
the same socket, PC board, node, switch, and CU (computing unit).
We therefore propose to define some of the unused bits to flag
these "local" conditions. This will not extend the field's size,
nor impact any other current use of the field.
Our intent is to add #define's to designate which bits stand for
which local condition. To make it easier to use, we will add a set
of macros that test the specific bit - e.g.,
OMPI_PROC_ON_LOCAL_SOCKET. These can be used in the code base to
clearly indicate which sense of locality is being considered.
We would also modify the orte_ess modules so that each returns a
uint8_t (to match the ompi_proc_t field) that contains a complete
description of the locality of this proc. Obviously, not all
environments will be capable of providing such detailed info. Thus,
getting a "false" from a test for "on_local_socket" may simply
indicate a lack of knowledge. This is acceptable for our purposes
as the algorithm will simply perform sub-optimally, but will still
work.
Please feel free to comment and/or request more information.
Ralph
_______________________________________________
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
