Messages in this thread | | | Date | Tue, 14 Oct 2014 03:49:52 -0400 | From | Rik van Riel <> | Subject | Re: [PATCH RFC 1/5] sched,numa: build table of node hop distance |
| |
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@redhat.com 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. >
| |