Once IRQ thread completes[for that matter any process], it will be scheduled out. The answer to your Qs depends on how you are using IRQ handler. If it is threaded and if you can afford to yield, use sleep of any kind in your handler to yield to other process. If the IRQ is non-threaded, then make sure your handler is atomic. So my point is RT kernel is fine, it is upto to the user how they prefer to use it. HTH, Mani On Thu, Sep 23, 2010 at 9:42 PM, Sri Ram Vemulpali <sri.ram.gmu06@xxxxxxxxx> wrote: > 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 > -- Thanks, Manik Think twice about a tree before you take a printout -- 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
