Doubt: Does RT patch reduce interrupt latency?

Doubt: Does RT patch reduce interrupt latency?

[Sbs]

Hi All,

(Sorry if I am asking this on a wrong list. Please let me know the
correct list for this question)

We have a system which needs to be connected to a device that will
produce an interrupt during every msec. So, we want interrupt
latencies less than 1 msec (else we will miss interrupts). We tried
measuring interrupt latencies with RT patch applied. However, the
results that he got suggested that after applying patches, the worst
case latency went up.

>From what I read and understood from the site is that, the patch will
cause this kind of behaviour. Is this correct? (" Converting interrupt
handlers into preemptible kernel threads:" - RT wiki FAQ)  I have seen
some other site mentioning about rtirq patch (for 2.4). What is good
for my scenario? Should I apply an RT patch at all? Or is there
something else that I need to see?

Thanks in advance,

Regards,
Sbs

Re: Doubt: Does RT patch reduce interrupt latency?

[Sven-Thorsten Dietrich]

On Fri, 2009-07-24 at 23:41 +0530, Sbs wrote:
> Hi All,
> 
> (Sorry if I am asking this on a wrong list. Please let me know the
> correct list for this question)
> 
> We have a system which needs to be connected to a device that will
> produce an interrupt during every msec. So, we want interrupt
> latencies less than 1 msec (else we will miss interrupts). We tried
> measuring interrupt latencies with RT patch applied. However, the
> results that he got suggested that after applying patches, the worst
> case latency went up.
> 
> From what I read and understood from the site is that, the patch will
> cause this kind of behaviour. Is this correct? (" Converting interrupt
> handlers into preemptible kernel threads:" - RT wiki FAQ)  I have seen
> some other site mentioning about rtirq patch (for 2.4). What is good
> for my scenario? Should I apply an RT patch at all? Or is there
> something else that I need to see?
> 

Did you raise the priority for the 1 ms IRQ thread?

> Thanks in advance,
> 
> Regards,
> Sbs
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Doubt: Does RT patch reduce interrupt latency?

[Darren Hart]

Sbs wrote:
> Hi All,
> 
> (Sorry if I am asking this on a wrong list. Please let me know the
> correct list for this question)
> 
> We have a system which needs to be connected to a device that will
> produce an interrupt during every msec. So, we want interrupt
> latencies less than 1 msec (else we will miss interrupts). We tried
> measuring interrupt latencies with RT patch applied. However, the
> results that he got suggested that after applying patches, the worst
> case latency went up.

As I understand it, if you are doing your processing via interrupts, the 
your latency to start processing interrupts will increase on average 
with the PREEMPT_RT patch.  There is additional scheduling overhead 
involved, and as Sven pointed out, if you don't bump the prio of the 
interrupt you care about, you can see MUCH higher latencies.

The PREEMPT_RT patch adds things like the rt-mutex replacement of most 
spinlocks, which adds preemption points and enable Priority Inheritance 
within the kernel, but this is all geared towards enable real-time 
applications.  If you just want fast OS processing of interrupts, then 
mainline provides you with a nice non-preemptible kernel side interrupt 
implementation that won't be affected by things like applications :-)

Please slap me if I've misrepresented PREEMPT_RT somehow. (I'm sure no 
invitation is actually required ;-)


-- 
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team

Re: Doubt: Does RT patch reduce interrupt latency?

[Sbs]

> Did you raise the priority for the 1 ms IRQ thread?

Sorry, this test was done by one of my team-mate. I should have
gathered enough information before mailing. I will check with him and
if that was not done, we will try again with raised priority. Then I
will get back to the list with more details and queries.

However, we did use the nodelay flag while requesting the IRQ. If
nodelay flag is used, does the priority still matter? Doesn't the use
of this flag make the kernel to treat this interrupt in the
traditional way? Are we really making use of any rt capability?

Btw, we are testing this on ARM platform.

Thanks,
Sbs

>
>> Thanks in advance,
>>
>> Regards,
>> Sbs
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Doubt: Does RT patch reduce interrupt latency?

[Sven-Thorsten Dietrich]

On Sun, 2009-07-26 at 08:51 +0530, Sbs wrote:
> > Did you raise the priority for the 1 ms IRQ thread?
> 
> Sorry, this test was done by one of my team-mate. I should have
> gathered enough information before mailing. I will check with him and
> if that was not done, we will try again with raised priority. Then I
> will get back to the list with more details and queries.
> 
> However, we did use the nodelay flag while requesting the IRQ. If
> nodelay flag is used, does the priority still matter? Doesn't the use
> of this flag make the kernel to treat this interrupt in the
> traditional way? Are we really making use of any rt capability?
> 

In general, when using nodelay, this would be the highest effective
priority for an IRQ.

Are there nested PICs? Keep in mind that threads mask off IRQ lines
until they have run, so you may want to make sure that all the lines
that handle IRQ cascade are also NODELAY. 

> Btw, we are testing this on ARM platform.
> 
> Thanks,
> Sbs
> 
> >
> >> Thanks in advance,
> >>
> >> Regards,
> >> Sbs
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> >

Re: Doubt: Does RT patch reduce interrupt latency?

[Sbs]

> As I understand it, if you are doing your processing via interrupts, the
> your latency to start processing interrupts will increase on average with
> the PREEMPT_RT patch.  There is additional scheduling overhead involved, and
> as Sven pointed out, if you don't bump the prio of the interrupt you care
> about, you can see MUCH higher latencies.
>
> The PREEMPT_RT patch adds things like the rt-mutex replacement of most
> spinlocks, which adds preemption points and enable Priority Inheritance
> within the kernel, but this is all geared towards enable real-time
> applications.  If you just want fast OS processing of interrupts, then
> mainline provides you with a nice non-preemptible kernel side interrupt
> implementation that won't be affected by things like applications :-)

Thank you for this clarification. This really made me think. In
mainline kernel, my interrupt will not be affected by other processes.
But, it can be affected by other interrupts in the system, right? So,
I still gain something from rt patch where I can scale down the
priority of other interrupts so that they don't come in the way of my
1 ms interrupt.

Now, if I got it correct, what I will have to see is whether this
advantage outweighs the disadvantage of context switching delays. A
quick search showed me http://choices.cs.uiuc.edu/ExpCS07.pdf. In page
25 they have listed time for context switches and interrupts. Those
figures are rather dismal (~few milli seconds). Can someone familiar
with ARM here tell me whether these numbers can be trusted? From the
rt wiki I see that, on ARM, worst case latency is less than 300us. I
will anyway repeat the tests that we did so far and will post the
results again.

@Sven: Just saw your reply. Thank you for the caution about nested
PICs. I will check this also while repeating the tests.

> Please slap me if I've misrepresented PREEMPT_RT somehow. (I'm sure no
> invitation is actually required ;-)

Since no one has done this so far, I trust you :)

>
>
> --
> Darren Hart
> IBM Linux Technology Center
> Real-Time Linux Team
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Doubt: Does RT patch reduce interrupt latency?

[Stefan Agner]

Hi,



> Thank you for this clarification. This really made me think. In
> mainline kernel, my interrupt will not be affected by other processes.
> But, it can be affected by other interrupts in the system, right? So,
> I still gain something from rt patch where I can scale down the
> priority of other interrupts so that they don't come in the way of my
> 1 ms interrupt.
Yes this is correct...

> Now, if I got it correct, what I will have to see is whether this
> advantage outweighs the disadvantage of context switching delays. A
> quick search showed me http://choices.cs.uiuc.edu/ExpCS07.pdf. In page
> 25 they have listed time for context switches and interrupts. Those
> figures are rather dismal (~few milli seconds). Can someone familiar
> with ARM here tell me whether these numbers can be trusted? From the
> rt wiki I see that, on ARM, worst case latency is less than 300us. I
> will anyway repeat the tests that we did so far and will post the
> results again.
I did such messures in my diploma work, its written in german but you should 
be able to read the figures (the messures are done on an arm cpu):
http://www.agner.ch/linuxrealtime/Linux-Realtime-Faehigkeiten.pdf

PDF Page 47 and following are interessting. You can see the 
"Durchschnittslatenzzeiten" (average latencies) rt compared with mainline

Bye
Stefan