Rene Gollent - 2009-03-16 14:47 :
On Mon, Mar 16, 2009 at 6:02 AM, Christian Packmann <Christian.Packmann@xxxxxx> wrote:Hard affinity can be very useful on SMT systems by scheduling one int-heavy and one FP-heavy thread to the same core, to make maximum use of execution resources.The problem with this kind of idea is that it makes the running assumption that you're in control of the entire widget, which is tosay no other tasks are competing for the same resources.
Er, I am in control. This is my desktop machine. It just does what I tell it to do. Nothing else. Do you accept any other behavior from your computers? :-)
> All it takes
is a single busy higher priority thread getting scheduled on the same core and your careful tuning has gone out the window, since I guarantee that it will run faster if the scheduler is able to drop it onto an idle core on a different CPU than if it can't run at all, FSB latency or not.
Finally, a sound technical reason against hard affinity. Thank you.Which only becomes a problem if you run two programs using hard affinity at the same time which try to use the same cores/threads. Otherwise the scheduler will push the non-bound threads on the idle cores.
How much of a problem this would be in practice is another thing. I assume that only a small minority of programs (<0.1%) will ever use hard affinity. And by providing information about "occupied" hardware threads, this might be alleviated by allowing programs using hard affinity to simply select other cores/threads (of which there will be *many* in a few years). So, this appears solvable for the most part. And if a user tries to run several programs with high computational load, he can't be helped anyway. The machine will perform terrible, hard affinity or no.
Christian
