Messages in this thread | | | Subject | Re: Plumbers: Tweaking scheduler policy micro-conf RFP | From | Peter Zijlstra <> | Date | Sun, 20 May 2012 01:13:01 +0200 |
| |
On Sat, 2012-05-19 at 10:08 -0700, Linus Torvalds wrote: > Don't try to build up some perfect NUMA topology and then > try to see how insanely well you can match a particular machine. Make > some generic "roughly like this" topology with (say) four three of > NUMAness, and then have architectures say "this is roughly what my > machine looks like".
> In particular, don't even try to give random "weights" to how close > things are to each other. Sure, you can parse (and generate) those > complex NUMA tables, but nobody is *ever* smart enough to really use > them. Once you move data between boards/nodes, screw the number of > hops. You are NOT going to get some scheduling decision right that > says "node X is closer to node Y than to node Z". Especially since the > load is invariably going to access non-node memory too *anyway*.
I suspect this is related to the patch I recently did that creates numa levels from the node_distance() table.
The fact is, that patch removed arch specific code. And yes initially I tried to use the weights for more than simply creating the balance levels but I've already realized that was a mistake and removed that part.
So currently all it does is create load-balance levels based on how far apart nodes are said to be and decrease the balance rate roughly proportional to how many cpus are in each level.
The node_distance() table is mostly already a fabrication of the arch/firmware; some people do exactly what you suggested, expose simple groups of board vs rest and not bother with fine details.
I used the node_distance() table simply because this was an existing arch interface that provides exactly what was needed and is used for exactly this purpose in the mm/ part of the kernel as well.
| |