Something to note about an RT kernel, and how it differs from the “stock” kernel, is how the scheduler can be customized. In any kernel one has a scheduler to prioritize which hardware or software interrupt will run when there are more interrupts than CPU cores available. A default kernel might schedule for average throughput, e.g., to take advantage of cache hits might mean putting off running another process even though it has waited. The concept of hard realtime is that the prioritized thread or process must always be able to run exactly with its defined time. Should this higher priority process be able to execute within some defined time, then it will wait for another thread/process to finish before running. However, if the lower priority process would stop the higher priority from running within some defined time, then no matter what, this other process would be preempted and the higher priority would run.
In a true hard realtime system there won’t be cache. Average throughput from cache tends to be thrown out since although cache hits can improve speed, a miss causes harm to the timing of execution no longer being predictable. On a system where you have cache (including any PC architecture, or ARMv8-a, a Cortex-A series, of the Orin) this cannot be guaranteed, and so a scheduling algorithm for attempting realtime becomes “soft realtime”. There is actually more than one level of hard realtime, e.g., guarantees of a shadow core taking over in case of a hardware failure (think of a fighter jet’s control system or a spacecraft…it isn’t good enough at mach 1.2 to throw out the aircraft and pilot because an inexpensive part failed).
The most basic hard realtime for ARM would be the Cortex-M series. This has no hardware backup though, and isn’t necessarily hard realtime unless software is set up correctly. The ARM Cortex-R series is capable of true hard realtime. A Cortex-R has hardware-based aids in scheduling which the Cortex-M does not. Scheduling difficulty goes up exponentially with number of processes being managed, and probably four processes or fewer could be managed easily with a Cortex-M. As the environment becomes more complex, one needs the Cortex-R to avoid the scheduler itself becoming a liability to performance (predictability). Cortex-R, when multicore, also has the ability to choose either shadow cores which will automatically take over without the software ever knowing about the failure via hardware, or else simply choosing to use each core and not using shadow cores.
Very very few consumer or average computers have hard realtime capability. The CPU cores you know about on Jetsons are also only capable of soft realtime (if the software is patched for it). An exception is that the Image Signal Processor (ISP) and Audio Processing Engine (APE) have a low powered Cortex-R processor to deal with audio and video to some extent where hard realtime is needed. There are cases where people will custom program the APE to take advantage of this (at the cost of lost audio).
Once the RT kernel runs on a Jetson it won’t necessarily be some “automatic it just improves” thing. What RT scheduling does is to allow processes to be classified, and have priorities set for various classes. If you’ve not set up a priority, then you won’t necessarily see any benefit of this. Even if you do set this up, it can still fail to operate priorities in a required time due to cache hit/miss latencies. This is a software algorithm which can only operate within the hardware capabilities.