On Apr 24, 2007, at 3:51 AM, Bert Wesarg wrote:
>> You want to be able to query for the other two. It seems like we
>> should be able to have a very small number of functions to be able to
>> query for all of these. But it's unfortunately a little more complex
>> than this because:
>>
>> - one-to-one: (socket,core) -> processor ID
> out of question
>
>> - one-to-one: (socket,core) -> node ID
> IMHO redundant and not necessary
>
>> - one-to-one: processor ID -> (socket,core)
> out of question
>
>> - one-to-one: processor ID -> node ID
> out of question
>
>> - one-to-many: node ID -> (socket,core)
> interesting, but
>> - one-to-many: node ID -> processor ID
> i find this better
I think you misunderstand. I was not proposing 6 functions here; I
was simply stating the information relationships (one-to-one and one-
to-many).
> The above statements results from the following point of view: the
> node ID
> is only an attribute to the processor ID. The main advantage from
> this pov
> is, it makes the API very clear and simple. There is only one main
> mapping: (socket,core) <-> processor ID. And the node ID is just a
> needful
> extra information.
I understand that the node ID is only "extra information", but if
PLPA only provides lookups to get the node ID as a side-effect of the
processor ID or (socket,core) tuple, then an application that wants
to do NUMA-esque things based on the node of the processor will need
to create its own data structures or do iterative queries to find
processors / (socket,core) tuples on the same node.
Hence, my rationale for initiating a query with any of the three
entities (socket/core tuple, processor ID, node ID) is the following:
a) PLPA already has all the data
b) an app may have any one of the entities and need the other two
c) if more than one app needs to query based on information X, then
it should be in a library so that it doesn't have to be implemented
more than once
Hence my proposal:
>> 2. Have 3 functions (assuming we delete the 2 current plpa_map_to_*()
>> functions):
>>
>> - have (socket,core), want processor ID and/or node ID
>> plpa_map_from_socket_core(int socket, int core, int *processor_id,
>> int *node_id);
>> processor_id can be NULL or node_id can be NULL, but not both.
>>
>> - have processor ID, want (socket,core) and/or node ID
>> plpa_map_from_processor(int processor_id, int *socket, int *core,
>> int *node_id);
>> (socket,core) can be NULL or node_id can be NULL, but not both.
>>
>> - have node ID, want a list of processor IDs and/or a list of
>> (socket,core) tuples
>> plpa_map_from_node(int node_id, int *socket, int *core, int
>> *processor_id);
>> (socket,core) can be NULL or processor_id can be NULL, but not
>> both.
>> If you create a "non trivial" patch, I'll need to have an OMPI 3rd
>> party contribution agreement from you. It's unfortunately necessary
>> in today's legal software climate. :-(
> Convinced. Is it necessary to send this mail as a certified/registered
> mail or with an return receipt?
There's instructions on the form on how to submit it:
http://www.open-mpi.org/community/contribute/
If you can submit one now, great. My experience is that it can take
a while to get all the lawyers to understand and sign off on the
document. So if waiting a few months makes things easier, that's
also fine.
>> But if you can describe to me the stuff I need to parse in /sys to
>> get node mappings, I'm happy to add this functionality myself.
>
> In devices/system/node/ are directories named "node%d", in these
> directories are symbolic links to the "cpu%d" directories in
> devices/system/cpu/, or use the cpumap in theses directories, its a
> cpumask with the processor IDs in this node.
Excellent; thanks.
--
Jeff Squyres
Cisco Systems
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}