Setting affinity for third party applications that create threads

Setting affinity for third party applications that create threads

Hope this is the correct forum to ask this question.

We can use KMP_AFFINITY and associated infrastructure to set affinity for threads spawned by applications we've developed. And we can use numactl to bind a single-process third-party application to a core. What's available to bind threads spawned by a third-party process to a particular core? We can set what's effectively a CPU set using numactl for a third-party application. The threads spawned by a third-party process will stay within this CPU set but appear to move around between cores. I would be grateful for pointers on how we can bind threads spawned by a third-party process to a particular core



6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

hello David,

you can use affinity API to pin 3rd party threads to cores:

sched_setaffinity() for linux, cpuset_setaffinity() for FreeBSD or SetThreadGroupAffinity() for windows.


Do you mean there is a requirement not to link against libgomp or libiomp?  taskset may be of use

Thanks for the replies. My problem is how I can set affinity to cores with third-party applications. These are applications for which I don't have the code so I can't compile and link them.


Is there any way to fix a thread to a core for threads spawned by a third-party application for which the source code is unavailable?





From outside of a process, you're really only going to be able to control the affinity of the entire process.  Depending on how the application spawns its threads, you *might* be able to bind the process to the desired core, let the application spawn the thread, and then move the main process.  I don't really expect that to work, but it might be worth exploring if you absolutely have to pin the applications threads to individual cores.

If you're looking for an answer which is independent of which OS, MPI and threading model is used in the application, I think you're out of luck.  Your reference to numactl would seem to indicate linux with pthreads, in which case you could set up a separate taskset selection for each MPI process, giving each process a selection of hardware contexts, with an effect similar to what you would get by setting KMP_AFFINITY for each process when libiomp is in use.

I don't see you explaining why you like numactl for a single-process application but not for multiple processes.  I suppose numactl or taskset may be applicable only for MPI_THREAD_FUNNELED model, but you didn't say explicitly that you have something different in mind.

I guess you may not have meant to ask for an equivalent to KMP_AFFINITY which works for any pthreads application.  Standard equivalents to KMP_AFFINITY are OMP_PROC_BIND and OMP_PLACES, but I'm sure you could find applications built not so long ago against libraries not sufficiently up to date to support them.

Leave a Comment

Please sign in to add a comment. Not a member? Join today