This is the topic of CPU core “affinity”. See:
https://www.kernel.org/doc/Documentation/IRQ-affinity.txt
Keep in mind there are both “hardware” and “software” processes. Hardware uses drivers and will be told to run with a hardware interrupt (hardware IRQ), while programs which are not directly hardware will use software interrupts (soft IRQ). This latter divides up into soft IRQs in kernel space (e.g., a driver which does not directly access hardware; an example might be a checksum), or a user space process (software running in a program and probably in contact with the kernel services, but runs at a lower authority and is not a driver). Any hardware IRQ requires actual wiring to the core before its affinity can go to that core; one can schedule a hardware interrupt to run on a core it does not have access to, and the scheduler will end up rescheduling for the core it has actual access to. Most soft IRQs can run on any core.
Sometimes it is not an advantage to run a soft IRQ (either user space or kernel space) on a different core because that process might require access to hardware which runs only on a different core (it’d end up going back to another core anyway, or waiting for the driver to that other core for related hardware). It’s kind of hit and miss, you won’t know until you test.
Another reason why a different core might or might not help is that a pattern of cache hits or misses can occur. The CPUs used for a desktop computer, or the cores which you can see in a Jetson, all have cache for performance reasons. If the cache has seen some memory before, then it is fast to access that memory via cache. However, cache is a limited amount, and if you get a cache miss, then extra time is required to refill that cache line before using it. Any process combination which causes the other process’s (remember we are multitasking) cache to clear means the cache has to always be filled and you’d never get a cache hit. This is one reason one might move to a new core, to put only your process on the core, but some data is shared, e.g., suppose we are talking about a process that reads the disk a lot, and that disk might only be available on the first CPU core (it is a hardware IRQ and might have wiring only to the first core). In that case the first core might have cached the data, but then the other core has to get that data from the first core and this is a cache miss. The scheduler is the final authority on which core to use, and is what decides when a process runs; the scheduler is reasonably smart when it comes to understanding cache, and there is a reason why a lot of processes will run on the first core even when they could be spread out on different cores.
Experiment with affinity, but it isn’t necessarily a magic button. You might want to examine the hardware IRQ servicing via:
cat /proc/interrupts
(note that most of these run on CPU0, the first core; there are also statistics about rescheduling)
That file is not a real file, it exists in RAM and is a reflection of the running kernel. Each time you examine it the number of serviced IRQs will go up. To see it in a pager:
cat /proc/interrupts | less
Your process might be related to one of those; or if your two programs share data, then even if the workload is higher on a core, it is possible running them both on the same core is faster due to cache. See also this very short post:
https://forums.developer.nvidia.com/t/irq-balancing/126244/6
(it mentions how some pseudo files are used)
There are also more complicated ways of doing something more detailed. There is something called a “cgroup”, which is a way of creating certain logical groupings. One can assign one or more programs for a particular cgroup (search for “cset” and “affinity” and “linux” together on Google), and tweak the cgroup.