Re: ARM Linux Suitability for Real-time Application

Re: ARM Linux Suitability for Real-time Application

[Eugeny S. Mints]

Andrew Lewis wrote:
> I have recently been using Linux on the AT91RM9200 as a data 
> concentrator for a small (as yet unreleased) communications application.
> 
[snip]
> In order to run the radio successfully I need to be able to handle 
> interrupts within around 50us, and have interrupts run constantly for 
> between 20us and 200us (mostly at the low end).  I would expect there to 
> be three or four of these interrupts every 1000us, probably using about 
> 25% of the CPU power just to manage the radio deck.
> 
> This would makeup the real-time control element of the application.  If 
> I was writing this on bare metal, I would lock the high level interrupts 
> out to perform communications between the mainline and the interrupt 
> control paths for no more than 10us.
> 
[snip]

> The question is, would I be able to meet these time contraints if I 
> wrote a device driver running under Linux?  Especially important is 
> keeping the latency of handling the interrupts below 50us, and not 
> breaking anything by running 200us long interrupts.
> 
> I just wanted a general indication that such a driver is possible or 
> impossible before embarking on a more detailed investigation.
The rough answer is that it's impossible with vanilla kernel and 
possible   (as a rough approximation) with Ingo Molnar's real-time patch 
  http://redhat.com/~mingo/realtime-preempt/ which includes arm 
real-time port and hardirq-disable removal feature by Daniel Walker.

All linux real-time related discussions are going on LKML so first of 
all you might want to use LKML instead arm linux list for all real-time 
questions (thus I changed list in the header of the message).

As to concrete numbers you are interested in please take a look at 
"PREEMPT_RT vs I-PIPE: the numbers, part 2" thread on LKML which I 
believe presents most recent numbers.

The bottom line is that interrupt and preemption latencies for a kernel 
with RT patch are inbetween 15-150us. But of course even with real-time 
patch you have to perform _real_ fine tuning of your system to achieve 
such hard constraints you identified.

	Eugeny
> Best Regards,
> Andrew Lewis
> 
> -------------------------------------------------------------------
> List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
> FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
> Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php
> 
> 
> 

Re: ARM Linux Suitability for Real-time Application

[Russell King]

On Wed, Jun 22, 2005 at 12:55:45PM +0400, Eugeny S. Mints wrote:
> The bottom line is that interrupt and preemption latencies for a kernel 
> with RT patch are inbetween 15-150us. But of course even with real-time 
> patch you have to perform _real_ fine tuning of your system to achieve 
> such hard constraints you identified.

If you're just after some background process to run off interrupts with
minimal interrupt latency, the good news is that you don't have to modify
the kernel on ARM, and you certainly don't need any RT patches.

If you use the FIQ, then your FIQ latency will be the time it takes the
CPU to enter your FIQ function.  Since the kernel _never_ disables FIQs
in any way, FIQs have ultimate priority over everything else in the
system.

This does mean that you have to be careful if you want data to cross
the boundary between FIQ and the rest of the kernel since you can't use
any of the normal locking functions from FIQ mode.  Also, note that FIQ
code can not reside in modules.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: ARM Linux Suitability for Real-time Application

[Daniel Walker]

On Wed, 22 Jun 2005, Russell King wrote:

> If you're just after some background process to run off interrupts with
> minimal interrupt latency, the good news is that you don't have to modify
> the kernel on ARM, and you certainly don't need any RT patches.
> 
> If you use the FIQ, then your FIQ latency will be the time it takes the
> CPU to enter your FIQ function.  Since the kernel _never_ disables FIQs
> in any way, FIQs have ultimate priority over everything else in the
> system.
> 

Aren't FIQ's only on some ARM's ? 


Daniel

Re: ARM Linux Suitability for Real-time Application

[Russell King]

On Wed, Jun 22, 2005 at 09:52:40AM -0700, Daniel Walker wrote:
> On Wed, 22 Jun 2005, Russell King wrote:
> > If you're just after some background process to run off interrupts with
> > minimal interrupt latency, the good news is that you don't have to modify
> > the kernel on ARM, and you certainly don't need any RT patches.
> > 
> > If you use the FIQ, then your FIQ latency will be the time it takes the
> > CPU to enter your FIQ function.  Since the kernel _never_ disables FIQs
> > in any way, FIQs have ultimate priority over everything else in the
> > system.
> > 
> 
> Aren't FIQ's only on some ARM's ? 

Yes, but please read the original mail.  I think you'll find my reply
is completely relevant to the question being posed, which was based
upon the AT91RM9200 SoC.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: ARM Linux Suitability for Real-time Application

[Andrew Lewis]

Russell King wrote:
> On Wed, Jun 22, 2005 at 09:52:40AM -0700, Daniel Walker wrote:
> 
>>On Wed, 22 Jun 2005, Russell King wrote:
>>
>>>If you're just after some background process to run off interrupts with
>>>minimal interrupt latency, the good news is that you don't have to modify
>>>the kernel on ARM, and you certainly don't need any RT patches.
>>>
>>>If you use the FIQ, then your FIQ latency will be the time it takes the
>>>CPU to enter your FIQ function.  Since the kernel _never_ disables FIQs
>>>in any way, FIQs have ultimate priority over everything else in the
>>>system.
>>>
>>
>>Aren't FIQ's only on some ARM's ? 
> 
> 
> Yes, but please read the original mail.  I think you'll find my reply
> is completely relevant to the question being posed, which was based
> upon the AT91RM9200 SoC.

Thanks for the suggestions.  The FIQ solutions sounds like the one to 
use.  I'll probably do a little testing sometime in the next few weeks 
to determine the maximum loading I can place on the processor when 
running some of the other peripherals simultaneously.  If I have time 
I'll test the -RT patches as well and post up some numbers for this 
processor.