Re: [PATCH RFC 1/5] sched,numa: build table of node hop distance

From: Rik van Riel
Date: Tue Oct 14 2014 - 03:50:35 EST

On 10/14/2014 02:47 AM, Peter Zijlstra wrote:
On Sun, Oct 12, 2014 at 09:28:04AM -0400, Rik van Riel wrote:
On 10/12/2014 09:17 AM, Peter Zijlstra wrote:
On Wed, Oct 08, 2014 at 03:37:26PM -0400, riel@xxxxxxxxxx wrote:
+ sched_domains_numa_hops = kzalloc(sizeof(int) * nr_node_ids * nr_node_ids, GFP_KERNEL);
+ if (!sched_domains_numa_hops)
+ return;

That's potentially a _BIG_ table (1M for a 512 node system).
The node_distance has magic allocations and is of u8 size, is there any
way we can re-use node_distance and avoid a second O(n^2) allocation?

You are right, this should be a u8 at the least.

Beyond that, I am not convinced that merging things into
the same array is worthwhile, since (IIRC) nr_node_ids
should be set to the actual number of nodes on the system
by then.

The thing is, it looks like all you do is compare hop distance, and the
order of the hop distances is the exact same order as the regular numa
distance. I could not find a place where you use the actual hop value.

I use the actual hop distances when doing the scoring
for glueless mesh topologies, in patch 4/5.

So if all you're interested in is the relative ordering, that should be
the same for both.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at