Hello,
Jeff Squyres wrote:
> - Perhaps we should not use the type name cpuset_t since it is used
> for multiple different kinds of items (sockets, nodes, etc.). How
> about bitmap_t? E.g. (regardless of whatever the function names end
> up being):
>
> map_from_node_id(int node_id, plpa_bitmap_t *cpuset);
> get_node_set(plpa_bitmap_t *nodeset);
> ...etc.
Yes, this cpu-centric name bothered me too. But maybe bitmap_t sounds to
generic, how is idset_t? The problem with a new naming is, finally we need
a cpu_set_t for the affinity function! But that shouldn't be a problem, or?
>
> - Can we combine map_to_tuple() and map_to_node_id()? It seems silly
> to have 2 functions for that -- perhaps:
>
> map_to_tuple(int processor_id, int *socket, int *core, int *thread,
> int *node);
Yes, but than overload the map_to_processor_id function too:
map_to_processor_id(int socket, int core, int thread, int *processor_id,
int *node_id);
I have no problem with this function overloading. The number of functions
is already very high, and these two are definitive the root of all.
>
> - I wasn't fond of the use of "get_<foo>map" function names, mainly
> because it seems like we're overloading the use of the word
> "map" (map_from_<foo> and get_<bar>map). I suggest using some plain
> words, for example:
>
> orig suggestion: map_from_node_id(int node_id, bitmap_t *cpuset);
> 2nd suggestion: node_get_cpumap(int node_id, bitmap_t *cpumap);
> JMS suggestion: node_get_processor_ids(int node_id, bitmap_t
> *processor_ids);
Definitive more readable, except your last name:
tuple_get_threads(int socket, int core, bitmap_t *threads);
Here 'tuple' is a 2-tuple, but all other mentions of a 'tuple' is a
3-tuple'. On the other side socket_core_get_threads() is very long.
So long
Bert
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}