Hi Gregory, Thanks for clarification. I got it. So, the reason for checking in the locks whether need_resched is set, to call schedule and other "low latency patch" which checks need_resch after few lines of code execution, is to eliminate task latency. > Likewise, if the irq-thread is suddenly _not_ the highest priority, it will be preempted ASAP. ÂThis will happen either immediately as soon as the higher task enters RUNNING, or "at the conclusion of any critical section that the irq-thread may have entered". ÂSince -rt eliminates most critical sections (and makes the few that remain very short), this usually means the former. What is that situation where higher priority task needs to wait until some critical section is executed. So, at the end schedule is called. Can you please clarify such a case, because when high priority task is in RUNNING mode it is immediately executed. So, I do not see any use of checking for to schedule at the end of critical section. Correct me if I am wrong. Thanks. Regards, Sri. On Fri, Sep 24, 2010 at 7:56 PM, Gregory Haskins <ghaskins@xxxxxxxxxx> wrote: > Hi Sri, > >>>> On 9/24/2010 at 12:42 AM, in message > <AANLkTik=Lfxm1qnT4FG79k67CTcnPkOvVeAzVUS=SP3g@xxxxxxxxxxxxxx>, 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 > > Can you be more specific as to which interrupt task latency you are referring to? > >> 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 is some confusion here. ÂThe "after" in any thread context is already a schedule(), so I am not clear on what you are proposing we need to eliminate. > > If the irq-thread is the highest priority task, it will run to completion and then naturally schedule() as part of its "sleep" logic (such as joining a wait-queue). ÂThe scheduler will immediately elect the next highest RUNNING task (or idle, if none are available) as a result of the irq-thread going to sleep (there is no latency here, assuming you correctly prioritized the threads). > > Likewise, if the irq-thread is suddenly _not_ the highest priority, it will be preempted ASAP. ÂThis will happen either immediately as soon as the higher task enters RUNNING, or at the conclusion of any critical section that the irq-thread may have entered. ÂSince -rt eliminates most critical sections (and makes the few that remain very short), this usually means the former. > >> Â 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. > > I assert we already _do_. ÂIf you think otherwise, please clarify the scenario that concerns you. > > Kind Regards, > -Greg > > > -- 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
