Messages in this thread | | | Date | Thu, 16 Jan 2003 15:31:55 -0800 | From | "Martin J. Bligh" <> | Subject | Re: [PATCH 2.5.58] new NUMA scheduler: fix |
| |
> yes, i saw it, it has the same tying between idle-CPU-rebalance and > inter-node rebalance, as Erich's patch. You've put it into > cpus_to_balance(), but that still makes rq->nr_balanced a 'synchronously' > coupled balancing act. There are two synchronous balancing acts currently: > the 'CPU just got idle' event, and the exec()-balancing (*) event. Neither > must involve any 'heavy' balancing, only local balancing. The inter-node
If I understand that correctly (and I'm not sure I do), you're saying you don't think the exec time balance should go global? That would break most of the concept ... *something* has to distribute stuff around nodes, and the exec point is the cheapest time to do that (least "weight" to move. I'd like to base it off cached load-averages, rather than going sniffing every runqueue, but if you're meaning we should only exec time balance inside a node, I disagree. Am I just misunderstanding you?
At the moment, the high-freq balancer is only inside a node. Exec balancing is global, and the "low-frequency" balancer is global. WRT the idle-time balancing, I agree with what I *think* you're saying ... this shouldn't clock up the rq->nr_balanced counter ... this encourages too much cross-node stealing. I'll hack that change out and see what it does to the numbers.
Would appreciate more feedback on the first paragraph. Thanks,
M.
- 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/
| |