Ingo wrote:
> if_ there is a significant hierarchy between CPUs it
> should be represented via a matching sched-domains hierarchy,
Agreed.
I'll see how the sched domains hierarchy looks on a bigger SN2 systems.
If the CPU hierarchy is not reflected in the sched-domain hierarchy any
better there, then I will look to involve the "SN2 sched domain
hierarchy experts" in improving SN2 the sched-domain hierarchy.
Ok - that works. Your patch of yesterday provides just the tool
I need to measure this. Cool.
> i'll first try the bottom-up approach to speed up detection (getting to
> the hump is very fast most of the time).
Good.
> then we can let the arch override the cpu_distance() method
I'm not aware we need that, yet anyway. First I should see if
the SN2 sched_domains need improving. Take a shot at doing it
'the right way' before we go inventing overrides. I suspect
you agree.
> the migration cost matrix we can later use to tune all the other
> sched-domains balancing related tunables as well
That comes close to my actual motivation here. I hope to expose a
"cpu_distance" such as based on this cost matrix, to userland.
We already expose the SLIT table node distances (using SN2 specific
/proc files today, others are working on an arch-neutral mechanism).
As we push more cores and hyperthreads into a single package on one end,
and more complex numa topologies on the other end, this becomes
increasingly interesting to NUMA aware user software.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373,
1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
