From: "Eugeny S. Mints" <emints@ru.mvista.com>
To: Andrew Lewis <andrew-lewis@netspace.net.au>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
"Dwalker@Mvista. Com" <dwalker@mvista.com>
Subject: Re: ARM Linux Suitability for Real-time Application
Date: Wed, 22 Jun 2005 12:55:45 +0400 [thread overview]
Message-ID: <42B92791.9060800@ru.mvista.com> (raw)
In-Reply-To: <42B8F6FB.2090203@netspace.net.au>
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
>
>
>
next parent reply other threads:[~2005-06-22 8:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <42B8F6FB.2090203@netspace.net.au>
2005-06-22 8:55 ` Eugeny S. Mints [this message]
2005-06-22 9:02 ` ARM Linux Suitability for Real-time Application Russell King
2005-06-22 16:52 ` Daniel Walker
2005-06-22 17:22 ` Russell King
2005-06-23 3:44 ` Andrew Lewis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42B92791.9060800@ru.mvista.com \
--to=emints@ru.mvista.com \
--cc=andrew-lewis@netspace.net.au \
--cc=dwalker@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.