Messages in this thread | ![/](/images/icornerl.gif) | | Date | Sun, 3 Apr 2005 17:24:13 +0200 | From | Ingo Molnar <> | Subject | Re: [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/
| ![\](/images/icornerr.gif) |