Messages in this thread | | | From | Erich Focht <> | Subject | Re: [Lse-tech] Minature NUMA scheduler | Date | Mon, 13 Jan 2003 00:35:00 +0100 |
| |
On Friday 10 January 2003 17:57, Martin J. Bligh wrote: > This seems like the right approach to me, apart from the trigger to > do the cross-node rebalance. I don't believe that has anything to do > with when we're internally balanced within a node or not, it's > whether the nodes are balanced relative to each other. I think we should > just check that every N ticks, looking at node load averages, and do > a cross-node rebalance if they're "significantly out".
OK, I changed my mind about the trigger and made some experiments with the cross-node balancer called after every N calls of load_balance. If we make N tunable, we can even have some dynamics in case the nodes are unbalanced: make N small if the current node is less loaded than the average node loads, make N large if the node is averagely loaded. I'll send the patches in a separate email.
> The NUMA rebalancer > is obviously completely missing from the current implementation, and > I expect we'd use mainly Erich's current code to implement that. > However, it's suprising how well we do with no rebalancer at all, > apart from the exec-time initial load balance code.
The fact that we're doing fine on kernbench and numa_test/schedbench is (I think) understandeable. In both benchmarks a process cannot change its node during its lifetime, therefore has minimal memory latency. In numa_test the "disturbing" hackbench just cannot move away any of the tasks from their originating node. Therefore the results are the best possible.
Regards, Erich
- 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/
| |