RT process priority > Interrupts ?
In Linux, when a real time process is executing and an interrupt comes, will the RT process be preempted? Is RT process considered superior to interrupts? Best Regards, Sandeep Kumar
On Thu, 09 Apr 2015 10:59:20 +0900, manty kuma said:
In Linux, when a real time process is executing and an interrupt comes, will the RT process be preempted?
Is RT process considered superior to interrupts?
Think it through - that would imply that RT processes effectively run with interrupts disabled (or ignored, which amounts to the same thing). What would be the result of that? How would the system behave? Consider in particular that RT processes want a hard maximum on latency (and usually as low latency as you can get). Remember to consider the case of more than one RT process on a system.... For bonus points, work it out for both hard and soft IRQs.
A missed IRQ is not considered fatal but where as missing the upper time limit for an RT process will be considered fatal. Hence I think, as a simple solution, the process should not be preempted. Is it the case? On Thu, Apr 9, 2015 at 11:15 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 09 Apr 2015 10:59:20 +0900, manty kuma said:
In Linux, when a real time process is executing and an interrupt comes, will the RT process be preempted?
Is RT process considered superior to interrupts?
Think it through - that would imply that RT processes effectively run with interrupts disabled (or ignored, which amounts to the same thing). What would be the result of that? How would the system behave? Consider in particular that RT processes want a hard maximum on latency (and usually as low latency as you can get). Remember to consider the case of more than one RT process on a system....
For bonus points, work it out for both hard and soft IRQs.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Thu, 09 Apr 2015 15:30:42 +0900, manty kuma said:
A missed IRQ is not considered fatal but where as missing the upper time
Are you *sure* that ignoring an IRQ for an arbitrarily long time is non-fatal? (Hint - it may not be fatal to the *kernel*. Think bigger....)
limit for an RT process will be considered fatal. Hence I think, as a simple solution, the process should not be preempted.
What does missing an IRQ mean for the following: 1) Hardware that's spewing IRQs on a constant basis (think "data acquisition" where you have a A/D converter handing you 4K of data every millisecond, whether you're ready or not). If userspace decides to go compute-bound for 2ms in an RT thread (bad idea but sometimes it happens), how many blocks of data do you lose? 2) What does missing an IRQ do to the latency of a *different* RT thread that's waiting for I/O completion?
In Linux, when a real time process is executing and an interrupt comes, will the RT process be preempted?
Is RT process considered superior to interrupts?
Generally, interrupts always intercept processes as long as interrupts are enabled, but ...
A missed IRQ is not considered fatal but where as missing the upper time limit for an RT process will be considered fatal. Hence I think, as a simple solution, the process should not be preempted. Is it the case?
… to deal with situations like this, two rather different approaches exist to mitigate the situation of missing deadlines on process level: 1) RT-Preempt: The RT-Preempt Patch makes Kernel Threads from ISRs that by default run at RT priority 50. Thus, only a minimal Kickoff ISR is needed to trigger the related thread, so that RT processes running at priorities bigger than 50 are only preempted for a minimal amount of time. 2) Xenomai: Xenomai features a Dual-Kernel approach (RT-Domain and Non-RT Domain), in which all interrupts are virtualized. Thus, RT processes (those running in the RT-Domain) are being executed with a higher priority than virtualized interrupts, more or less again imposing only a minimal amount of preemption delay due to some Kickoff ISR part. However, there is no such mechanism available for vanilla kernels.
participants (3)
-
manty kuma -
Valdis.Kletnieks＠vt.edu -
Warlich, Christof