If your process is purely software and does not involve talking through some of the I/O (such as GPIO), then the scheduler would honor your request if no other higher priority process needs that core. Keep in mind that much depends on the nature of your process and we don’t know anything about your process…plus it depends on the nature of other processes.
More needs to be known about your process, e.g., is it a hardware I/O driver? What other drivers does it use as it runs, e.g., would it use a USB driver or GPIO? Does data come from disk, ethernet, so on?
One thing I am not clear on is if the GPU is accessible to all cores. I say this because the memory controller is accessible to all cores (and thus so is the GPU), but GPIO and some of the other hardware must go through CPU0. If GPU gets data from USB or ethernet drivers, then somewhere in that chain even if GPU runs from any core there will still be a limitation in getting data to the GPU…there would be an indirect dependency. Once data is in the GPU then I’d think it could run anywhere…if the driver is arranged wrong then what you’d see is part of the process running on CPU0 while obtaining data, and then the possibility of it migrating to another core…but if it is already on CPU0 I couldn’t say what the scheduler would do. What I’m getting at is that for anything running in kernel space the way you arrange its execution can change whether a core is available and whether the scheduler can or will honor affinity. For user space this typically is a separation of various parts of what the kernel does and will mostly go to the core you want when it isn’t hardware I/O. If caching is involved, then there will be some pressure to not migrate elsewhere.
Note that on a desktop multi-core PC there is a mechanism to be able to deal with hardware interrupts being sent to any core…a TX2 does not have this for hardware IRQs, and hardware IRQs are what start code running on any particular hardware driver. Software IRQs can always go wherever the scheduler wants it to go, but only CPU0 on a Jetson will run hardware IRQs (you might start a hardware IRQ elsewhere, but it will migrate to CPU0).
If this is a driver there comes a question about whether there are parts of the driver which depend on hardware, and yet software-only parts could run separately…you could shorten the time needed on hardware and spawn the rest to kthreadd…the kthreadd part could be bound to a different core, the hardware-only part would demand running on CPU0 in competition with everything else.
A second thing to consider is running your process at a higher priority (a lower “nice” value). You can get into trouble if you run yours at too high of a priority since you end up with a priority inversion in some cases, e.g., if its priority is too high but it uses the eMMC and eMMC itself can’t respond because your process is blocking it. Generally speaking a process runs by default at a nice value of “0”, but you can set it to “-2” and get quite a priority boost in comparison to other user space and priority 0 processes. If you get to “-2” and it doesn’t help, then priority changes won’t help in general (if you try “-5” you’re just asking for trouble…either the code is arranged well to do this or it isn’t). This applies a significant amount of pressure on the scheduler to give your process priority instead of the other way around.
You can use the “nice” command on command line, plus there is a C API version. If you run “man -a nice”, then as you quit one man page section it’ll bring up the next man page section’s information (section 2 has the C API information, section 1 has the command line information). The command “renice” can alter an existing process. Only root can nice or renice to a negative value (to a higher priority…though the section 2 man page mentions an exception…see “RLIMIT_NICE” and the referenced “getrlimit” man page).
Dusty mentioned RedHawk, which is hard realtime. Linux can be used for soft realtime, but if you need guaranteed deterministic realtime then you need something like RedHawk. Even RedHawk would not be able to migrate to different cores for some component which requires wiring which only goes to CPU0…so it depends again on the nature of your program and the resources it uses. You would however get much more control over getting your process to run when you want…the overall speed of the system may not be quite as fast, but it would be more predictable and give you more control.