* Peter Zijlstra [off-list ref] [2021-05-28 10:43:23]:

On Mon, May 24, 2021 at 09:48:29PM +0530, Srikar Dronamraju wrote:

quoted

* Valentin Schneider [off-list ref] [2021-05-24 15:16:09]:

quoted

quoted

I suppose one way to avoid the hook would be to write some "fake" distance
values into your distance_lookup_table[] for offline nodes using your
distance_ref_point_depth thing, i.e. ensure an iteration of
node_distance(a, b) covers all distance values [1]. You can then keep patch
3 around, and that should roughly be it.

Yes, this would suffice but to me its not very clean.
static int found[distance_ref_point_depth];

for_each_node(node){
	int i, nd, distance = LOCAL_DISTANCE;
		goto out;

	nd = node_distance(node, first_online_node)
	for (i=0; i < distance_ref_point_depth; i++, distance *= 2) {
		if (node_online) {
			if (distance != nd)
				continue;
			found[i] ++;
			break;
		}
		if (found[i])
			continue;
		distance_lookup_table[node][i] = distance_lookup_table[first_online_node][i];
		found[i] ++;
		break;
	}
}

But do note: We are setting a precedent for node distance between two nodes
to change.

Not really; or rather not more than already is the case AFAICT. Because
currently your distance table will have *something* in it
(LOCAL_DISTANCE afaict) for nodes that have never been online, which is
what triggered the whole problem to begin with.

Only after the node has come online for the first time, will it contain
the right value.

So both before and after this proposal the actual distance value changes
after the first time a node goes online.

Yes that's unfortunate, but I don't see a problem with pre-filling it
with something useful in order to avoid aditional arch hooks.

Okay,

Will post a v2 with prefilling.
Thanks for the update.

-- 
Thanks and Regards
Srikar Dronamraju