CONFIG_PREEMPT_RT in real-world applications

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hello embedded-linux folks,

I am kind of confuded how a piece of realtime code would look like using
Ingo Molnars CONFIG_PREEMPT_RT patch.

What would I need to make a process realtime. How would I be able to
generate a somewhat exact timing, e.g. for a control circuit. From the
perspective of a normal Linux system programming guy /dev/rtc comes
to mind.

For the realtime stuff, would it be enough to just use a negative nice-level
and a SCHED_FIFO policy?

Is there any kind of realtime programming Howto which I have not found
searching the web? Or is this just an exmple of another piece of fine but
undocumented work which is quite common in the Open-Source world?

Sven

--
                       This APT has Super Cow Powers.
                    (apt-get --help on debian woody)

We've slightly trimmed the long signature. Click to see the full one.
Re: CONFIG_PREEMPT_RT in real-world applications

Quoted text here. Click to load it

take a look at www.rtai.org

regards,
  Mario


Re: CONFIG_PREEMPT_RT in real-world applications

Quoted text here. Click to load it

RTAI is not what I am talking about. Its Ingo Molnars patches for the
Standard Kernel aka Realtime preemtion.

Sven

--
"Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition,
 die anderen sind einfach von sich aus unlogisch."
We've slightly trimmed the long signature. Click to see the full one.
Re: CONFIG_PREEMPT_RT in real-world applications
Hi Sven,

I don't have an answer, but:
- I guess you have read this: http://lkml.org/lkml/2005/6/7/256 . If not,
  the information is probably relevant to your question.
- The guys involved in that discussion should be able to answer you
(Ingo himself?).
- Maybe it's a question that can be posted on the kernel mailing list
itself (not sure about that, I haven't used it before, but I would guess
that not many embedded developpers have done what you are trying to do).
- I guess you also already know this article:
http://linuxdevices.com/articles/AT3479098230.html , but just in case...

Was just trying to help a little, since you haven't received any
relevant answer after nearly two days.

Good luck,

Regards,

Alain

Re: CONFIG_PREEMPT_RT in real-world applications

Quoted text here. Click to load it

I did not know it, but unfortunately it does not talk about
CONFIG_PREEMPT_RT anyway.

Sven

--
"The American news-media is no longer a news source; it is a
cheerleading squad." (unknown source)

We've slightly trimmed the long signature. Click to see the full one.
Re: CONFIG_PREEMPT_RT in real-world applications

Quoted text here. Click to load it

Several approaches are "identical" from a users perspective.
Simpel rule: Highest priority process runs
The point of the different approaches is to ensure that this is correct.

Lets try an example, read from serial port (buffer in driver):
A process runs (A) - like idle process, web server, ...
- Interrupt arrives
- Handled by irq-handler in driver, driver collects characters until some
  limit is reached / special character is read.
- Irq handler now wakes up the process (B) waiting for this interrupt.
But here comes the problem. What was the process A doing.
1) Running in user space (the actual application code)
 No problem, when leaving from the interrupt it will be noticed that the
 current process should let another process run. A context switch will
 occur when leaving.
2) Running in system space (walking through all page descriptors trying
 to find a page to swap out). This is worse since the process might be
accessing shared structures - rules must be followed.
a) Wait for process to leave kernel space.
b) When doing stuff that can take time in the kernel - check if another
    higher priority stuff wants to run.
c) Use multiprocessor spinlocks, do not allow process switches while
    in a critical section.
d) Reduce critical sections by minimising spinlocks, do this by
    d1) Replacing them with semaphores
   d2) Add checks inside the spinlocks
e) Don't bother with the kernel at all, let the RT processes be handled
   by their own micro OS that sees Linux as one of its processes.
   Usually trying to use the same API (Posix) but you will not be able
   to use all services of Linux.

Quoted text here. Click to load it

But an ordinary file could be the source, consider
 tail -f /var/log/something
with a requirement that it should output "something" within two secons.

Quoted text here. Click to load it

nice-level is only used in SCHED_OTHER (and that is never Real Time)

Quoted text here. Click to load it

Look out for RT benchmarks, like http://www.gardena.net/benno/linux/audio
(Old but still valid)

/RogerL

Site Timeline