On 07/09/2012 08:40 AM, Peter Zijlstra wrote:
On Mon, 2012-07-09 at 14:23 +0200, Peter Zijlstra wrote:
It is not yet clear to me how and why your code converges.
I don't think it does.. but since the scheduler interaction is fairly
weak it doesn't matter too much from that pov.
Fair enough. It is just that you asked this same question
about Andrea's code, and I was asking myself that question
while reading your code (and failing to figure it out).
That is,.. it slowly moves along with the cpu usage, only if there's a
lot of remote memory allocations (memory pressure) things get funny.
It'll try and rotate all tasks around a bit trying, but there's no good
solution for a memory hole on one node and a cpu hole on another, you're
going to have to take the remote hits.
Agreed, I suspect both your code and Andrea's code will
end up behaving fairly similarly in that situation.
Again.. what do we want it to do?
That is a good question.
We can have various situations to deal with:
1) tasks fit nicely inside NUMA nodes
2) some tasks have more memory than what fits
in a NUMA node
3) some tasks have more threads than what fits
in a NUMA node
4) a combination of the above
I guess what we want the NUMA code to do to increase
the number of local memory accesses for each thread,
and do so in a relatively light weight way.
--
All rights reversed
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>