lkml.org 
[lkml]   [2005]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]

* Paul Jackson <pj@engr.sgi.com> wrote:

>
> 3) I was noticing that my test system was only showing a couple of
> distinct values for cpu_distance, even though it has 4 distinct
> distances for values of node_distance. So I coded up a variant of
> cpu_distance that converts the problem to a node_distance problem,
> and got the following cost matrix:

> The code (below) is twice as complicated, the runtime twice as long,
> and it's less intuitive - sched_domains seems more appropriate as
> the basis for migration costs than the node distances in SLIT tables.
> Finally, I don't know if distinguishing between costs of 21.7 and
> 25.3 is worth much.

the main problem is that we can do nothing with this matrix: we only
print it, but then the values get written into a 0/1 sched-domains
hierarchy - so the information is lost.

if you create a sched-domains hierarchy (based on the SLIT tables, or in
whatever other way) that matches the CPU hierarchy then you'll
automatically get the proper distances detected.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-04-06 13:31    [W:6.655 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site