|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [PATCH v3 03/17] xen/arm: implement node distance helpers for Arm
Hi Jan,
> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Subject: Re: [PATCH v3 03/17] xen/arm: implement node distance helpers for
> Arm
> >> However, looking at the code below, don't you mean to have the array
> >> pre-set to all NUMA_NO_DISTANCE?
> >
> > ...I am a bit puzzled about why pre-setting the array to all
> > NUMA_NO_DISTANCE matters here, as I think the node distance map will
> > be populated when parsing the device tree anyway no matter what their
> > initial values.
>
> From this patch alone it doesn't become clear whether indeed all array
> slots (and not just ones for valid nodes) would be populated. I think
> the code in the patch here would better not make itself dependent on
> behavior of code added subsequently (which may change; recall that a
> series may be committed in pieces).
Correct, I agree. I added a numa_init_distance() function (in patch #12) to
set all values to NUMA_NO_DISTANCE. The numa_init_distance() will be
called in the beginning of numa_init().
>
> >>> +unsigned char __node_distance(nodeid_t from, nodeid_t to)
> >>> +{
> >>> + /* When NUMA is off, any distance will be treated as remote. */
> >>> + if ( numa_disabled() )
> >>> + return NUMA_REMOTE_DISTANCE;
> >>
> >> Wouldn't it make sense to have the "from == to" special case ahead of
> >> this (rather than further down), thus yielding a sensible result for
> >> from == to == 0? And else return NUMA_NO_DISTANCE, thus having a
> >> sensible result also for any from/to != 0?
> >
> > Could you please elaborate a bit more about why 0 matters here?
>
> When NUMA is off, there's only one node - node 0. Hence 0 has special
> meaning in that case.
>
> > As from my understanding,
> > (1) If from == to, then we set the distance to NUMA_LOCAL_DISTANCE
> > which represents the diagonal of the matrix.
> > (2) If from and to is in the matrix range, then we return
> > node_distance_map[from][to].
>
> Provided that's set correctly. IOW this interacts with the other comment
> (which really I made only after the one here, just that that's of course
> not visible from the reply that I sent).
>
> > (3) Other cases we return NUMA_NO_DISTANCE.
>
> And when NUMA is off, it should be NUMA_NO_DISTANCE in _all_ other
> cases,
> i.e. ...
>
> > /* When NUMA is off, any distance will be treated as remote. */
> > if ( numa_disabled() )
> > return NUMA_REMOTE_DISTANCE;
>
> ... this return is wrong in that case (even if in reality this likely
> wouldn't matter much).
Thanks for the explanation! I think I now understand :) Would this diff below
look good to you then? Appreciate your patience.
unsigned char __node_distance(nodeid_t from, nodeid_t to)
{
- /* When NUMA is off, any distance will be treated as remote. */
+ if ( from == to )
+ return NUMA_LOCAL_DISTANCE;
+
+ /* When NUMA is off, any distance will be treated as unreachable (0xFF). */
if ( numa_disabled() )
- return NUMA_REMOTE_DISTANCE;
+ return NUMA_NO_DISTANCE;
/*
* Check whether the nodes are in the matrix range.
* When any node is out of range, except from and to nodes are the
- * same, we treat them as unreachable (return 0xFF)
+ * same, we treat them as unreachable (0xFF)
*/
if ( from >= ARRAY_SIZE(node_distance_map) ||
to >= ARRAY_SIZE(node_distance_map[0]) )
- return from == to ? NUMA_LOCAL_DISTANCE : NUMA_NO_DISTANCE;
+ return NUMA_NO_DISTANCE;
return node_distance_map[from][to];
}
Kind regards,
Henry
>
> Jan
>
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |