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/