I want to make sure that one of the Denver cores to run my specific proccess and nothing else, that process is a soft real-time code that I want to maximise its speed.
I know I can use taskset for affinity but that makes my process run on that core only but doesn’t make Linux not run other processes on that core.
There is also a boot option called isolcpus but I don’t want to edit the bootloader…
Any other way?
There are probably other ways, but if you know your process is running on only a single selected core (it should not be CPU0), then why not give your process a high priority? I suppose it might depend if this is a user space application or kernel space, but it sounds like you mean user space.
A normal user space priority is “0”. A higher priority to “not be as nice” to other processes, which would be a rather high priority for your process, would be “-5” or “-10” (you’re asking for trouble if go much higher priority without a really good reason). It requires root authority to become “less nice” (negative nice number for higher priority), but you can non-programmatically test this on the command line with the “nice” command (or the “renice” command.
If you are ok testing as root, then just use the “nice” command when starting your program. If you want to run your program as a regular user, then start it, find the PID, and use sudo with “renice”. If all of this works out, then there are C functions you can call to do this inside of your program (which won’t get around needing root authority).
Check out “man -a nice” and “man renice”.
If that does not do the job, then you can look into actually excluding processes other than yours from working on the CPU core. Just a reminder since it is important, but do not mess with CPU0. Only do this on other cores.
So what you suggest is using taskset and nice to:
a. Allow my proccess to only run at one core
b. Give it highest priority
Does b garuntrees that the kernel won’t schedule another user space proccess to that core?
This would not guarantee it. However, it would mean the other processes would get bumped anyway. Probably this is the first step regardless of other steps.
It was suggested by @Honey_Patouceul that perhaps using isolcpus to mark cores as inaccessible by processes would perhaps still allow processes which were specifically set by affinity to still run the desired process on that core without stopping other processes. We don’t know though if that would work, it hasn’t been tested, but it is very easy to test. Still, you’d want to first use affinity. There are likely multiple ways to keep other processes away, but I would not bother with this until you know affinity plus priority won’t work.
How do you use isolcpus with the Jetpack? It is suppose to be a boot parameter no?
Yes, it is a kernel boot argument.
Not sure this works for any L4T release, but if you have extlinuxconf working, it should be easy to test.
Here we will reserve CPU5 (don’t try CPU0):
As root, edit file /boot/extlinux/extlinux.conf and copy the default config ‘primary’ block, paste it below, rename the new config from default to test, and in its APPEND section, add isolcpus=5
If you have a serial console, you would have a few seconds during boot for selecting the test config.
If you don’t have a serial console now, but would be able to get one in case of problem, then you can try just setting DEFAULT in the second line of extlinux.conf as test instead of default.
Reboot and log in. Then check that CPU5 has been isolated:
cat /sys/devices/system/cpu/isolated
5
If you look at affinity of process init (1), you should see CPU5 is not available for scheduling:
taskset -cp 1
pid 1's current affinity list: 0-4
Running tegrastats, you should see CPU5 to be always 0%.
So you would now run your process onto CPU5 with taskset:
taskset -c 5 your_app
and see the usage with tegrastats.