<div dir="ltr"><div>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.<br><br></div><div>Is it the case?<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 9, 2015 at 11:15 AM, <span dir="ltr"><<a href="mailto:Valdis.Kletnieks@vt.edu" target="_blank">Valdis.Kletnieks@vt.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, 09 Apr 2015 10:59:20 +0900, manty kuma said:<br>
> In Linux, when a real time process is executing and an interrupt comes,<br>
> will the RT process be preempted?<br>
><br>
> Is RT process considered superior to interrupts?<br>
<br>
</span>Think it through - that would imply that RT processes effectively run with<br>
interrupts disabled (or ignored, which amounts to the same thing). What would<br>
be the result of that? How would the system behave? Consider in particular<br>
that RT processes want a hard maximum on latency (and usually as low latency as<br>
you can get). Remember to consider the case of more than one RT process on a<br>
system....<br>
<br>
For bonus points, work it out for both hard and soft IRQs.<br>
<br>_______________________________________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org">Kernelnewbies@kernelnewbies.org</a><br>
<a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" target="_blank">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
<br></blockquote></div><br></div>