0

I want to bind a process to a specific core #0 (cpu affinity) via

taskset -c 0 ./run_prog

while the program it self is running on core #0, operating system may decide to run other background and active process to core #0. In other word, that command strictly limits run_prog to core #0 but doesn't prevent other process to run on core #0 and that is bad!

Is there any way to write a bash script to first prevent active processes running on core #0 and then run that taskset command?

mahmood
  • 23,197
  • 49
  • 147
  • 242
  • I've heard this question a couple of times, and it was always being asked out of a misunderstanding of how simultaneous multiprocessing works. First of all: Why do you need your process on core #0? Do you have a reason? – Marcus Müller Jun 07 '15 at 08:38
  • 1
    typically, the linux kernel is quite efficient at scheduling tasks to processors in a manner that minimizes the negative effects that either process migration or a single-core-bottleneck would bring. In fact, it's very rare to see someone actually gain performance by manually setting affinities, and that usually only happens when the userland process is closely communicating with a kernel module which for some hardware or implementation reason is inherently single-threaded and can't easily be migrated. – Marcus Müller Jun 07 '15 at 08:41
  • Your question itself shows a minor misunderstanding: Affinity means that the kernel knows that it should schedule that process on the given core. Hence, other processes will automatically be migrated away from that core and only be running there if your desired task leaves a lot of that core unused. To change the "priority" your process has in CPU allocation, just change its `nice` value. – Marcus Müller Jun 07 '15 at 08:43
  • @Marcus Müller: The reason is performance measurement by isolating the running process. Regarding the second comment, that mean we have to rely on OS scheduler because it will not run a background process on a core which is currently utilized 100% while there are idle cores. Thanks – mahmood Jun 07 '15 at 08:52
  • what you're measuring is not the performance of the process isolatedly, but of the process, bound to a single CPU! For a single-threaded process that's ok, but imagine that your process might have multiple threads -- these all would normally run on different cores, and overall performance would be *much* higher. Generally, try just minimizing non-process workloads on your machine (ie. run without a window manager/session manager running, stop all non-essential services) and use a very small `nice` value -- that measurement might be relatively precise. – Marcus Müller Jun 07 '15 at 09:00
  • Also, the `time` command allows you to know how much time a process spend totally (including waiting), occupying CPU as userland process, and occupying CPU in system calls -- I think that might fit your needs well enough :) – Marcus Müller Jun 07 '15 at 09:02
  • I'll think I take my comments and add them as an answer, to save them for the afterworld :) – Marcus Müller Jun 07 '15 at 09:15

1 Answers1

1

I've discussed this in a series of comments to the original question, but I think it's "the answer to the underlying problem" rather than a specific answer to your specific question, so here we go:

I've heard this question a couple of times, and it was always being asked out of a misunderstanding of how simultaneous multiprocessing works. First of all: Why do you need your process on core #0? Do you have a reason?

typically, the linux kernel is quite efficient at scheduling tasks to processors in a manner that minimizes the negative effects that either process migration or a single-core-bottleneck would bring. In fact, it's very rare to see someone actually gain performance by manually setting affinities, and that usually only happens when the userland process is closely communicating with a kernel module which for some hardware or implementation reason is inherently single-threaded and can't easily be migrated.

Your question itself shows a minor misunderstanding: Affinity means that the kernel knows that it should schedule that process on the given core. Hence, other processes will automatically be migrated away from that core and only be running there if your desired task leaves a lot of that core unused. To change the "priority" your process has in CPU allocation, just change its nice value.

The reason is performance measurement by isolating the running process. Regarding the second comment, that mean we have to rely on OS scheduler because it will not run a background process on a core which is currently utilized 100% while there are idle cores.

what you're measuring is not the performance of the process isolatedly, but of the process, bound to a single CPU! For a single-threaded process that's ok, but imagine that your process might have multiple threads -- these all would normally run on different cores, and overall performance would be much higher. Generally, try just minimizing non-process workloads on your machine (ie. run without a window manager/session manager running, stop all non-essential services) and use a very small nice value -- that measurement might be relatively precise.

Also, the time command allows you to know how much time a process spend totally (including waiting), occupying CPU as userland process, and occupying CPU in system calls -- I think that might fit your needs well enough :)

Marcus Müller
  • 34,677
  • 4
  • 53
  • 94