Hi Gregory, Thanks for the explanation. I got a grasp of what you said. So, the whole preempt rt is made preemptible, even in the interrupt context. the IRQ now executes as thread, so that it can be preempted. Now the question is, usually this interrupt task latency occurs when IRQ thread finishes and sets need_resch. So this is checked in the locks, so that long critical section determines when to schedule, which is non-deterministic. why do not we eliminate this by calling schedule immediately after IRQ thread context. I think there can be a solution. If such solution exists we will not have two kinds of patches "low latency" and "preempt" patches of RT. Can you please explain, is there any reason or bottle neck to implement solution to call schedule immediately after IRQ thread context. Thanks. Regards, Sri. On Thu, Sep 23, 2010 at 8:05 PM, Gregory Haskins <ghaskins@xxxxxxxxxx> wrote: > Hi Sri, > >>>> On 9/23/2010 at 07:00 PM, in message > <AANLkTi=EmZJrC+Dmq_-Oijew2uUQ8Xo1y_xzeAZsaS01@xxxxxxxxxxxxxx>, Sri Ram > Vemulpali <sri.ram.gmu06@xxxxxxxxx> wrote: >> Hi all, >> >> Â Â Â ÂI have a doubt regarding interrupt task latency. >> Â Â Â ÂI know that whenever interrupt context and its associated BH >> are finished, then need_resch is checked whether to call schedule >> Â Â Â ÂIn such case then the latency is deterministic > > How? ÂIn a way, you answered your own question: ÂAssume top-half takes X microseconds, bottom-half takes Y, and the needs_resched()+schedule takes Z. ÂSo in your scenario, you have a latency of X+Y+Z. ÂWhat makes you so sure that X and Y are constants for all possible TH+BH combinations? ÂIt doesn't take much imagination to think of common scenarios that are non-deterministic in this context: ÂThink of things like a netif napi_poll operation dequeuing a variable number of packets and you get the idea. > > In addition, what makes you sure that X and Y are reasonably short? ÂRT isn't simply about "determinism". ÂIts about "deterministically low latency". ÂIf I told you that X and Y are fixed constants equal to 20 seconds each, that would be deterministic but yet result in a completely useless system ;) > > What RT does, in essence, is try to make as many things as possible a scheduleable task so that a task priority may be assigned and a scheduling policy may be employed against that priority constraint. ÂThe corollary to that is that RT also tries to minimize the number of places that are _not_ scheduleable tasks by getting rid of most in_atomic() sections, etc with various tricks. ÂThe net result is that the time spent in_atomic() is deterministically very short, allowing your task priority policy to govern what code is the most critical to run next. ÂThis means much much more than the fact that your scenario above _eventually_ checked if it needed to reschedule after some potentially arbitrarily long critical section. > > HTH > -Greg > > >>and one need not >> to bother about this latency. Why is that rt still considers this as >> Â Â Â Âbottle neck on this issue. >> >> Â Â Â ÂAny explanation is appreciated. Thanks. >> >> -- >> Regards, >> Sri. >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at Âhttp://vger.kernel.org/majordomo-info.html > > > > -- Regards, Sri. -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
