Binding considerations

There are several issues to consider before you use the process binding.

Binding can be useful for CPU-intensive programs that experience few interrupts. It can sometimes be counterproductive for ordinary programs because it might delay the redispatch of a thread after an I/O until the processor to which the thread is bound becomes available. If the thread is blocked during an I/O operation, it is unlikely that much of its processing context remains in the caches of the processor to which it is bound. The thread is better served if it is dispatched to the next available processor.

Binding does not prevent other processes from being dispatched on the processor on which you bound your process. Binding is different from partitioning. Using rsets or exclusive rsets allows a set of logical processors to be dedicated for a specific workload. Therefore, a higher priority process might be dispatched on the processor where you bind your process. In this case, your process is not dispatched on other processors, and therefore, you the performance of the bound process is not increased. Better results might be achieved if you increase the priority of the bound process.

If you bind a process on a heavily loaded system, you might decrease its performance because when a processor becomes idle, the process is not able to run on the idle processor if it is not the processor on which the process is bound.

If the process is multithreaded, binding the process binds all its threads to the same processor. Therefore, the process does not take advantage of the multiprocessing, and performance is not improved.