Hello,
I've been trying to use L4-Linux as a real-time platform for a control application. The application was developed based on VxWorks, but ported to Linux lately. Unfortunately, as you know, Linux allows usual processes to block a real-time process for durations of 100 ms or more. I found that a process of L4-Linux can preempt the Linux server if the process is given a priority higher than that of Linux, and can continue with its work as far as it does not call Linux for services. I actually tested it on a PC-compliant VME CPU board. Interrupt latency in the worst case was less than 1 ms, even with a disk I/O background. I'm wondering if this mailing-list accepts application related issues as well. If so, I'd like to ask you : 1) Is that kind of idea crazy? 2) Is there anyone who tried (or is going to try) something like that? 3) Is L4-Linux going to keep up with the revisions of Linux in the future? I'll appreciate any suggestion, comment and criticism.
Thanks in advance.
J. Odagiri
Hi,
On Friday 15 June 2001 12:58, Jun-ichi Odagiri wrote:
I've been trying to use L4-Linux as a real-time platform for a control application. The application was developed based on VxWorks, but ported to Linux lately.
Great!
Unfortunately, as you know, Linux allows usual processes to block a real-time process for durations of 100 ms or more. I found that a process of L4-Linux can preempt the Linux server if the process is given a priority higher than that of Linux, and can continue with its work as far as it does not call Linux for services. I actually tested it on a PC-compliant VME CPU board. Interrupt latency in the worst case was less than 1 ms, even with a disk I/O background. I'm wondering if this mailing-list accepts application related issues as well. If so, I'd like to ask you :
Yes, it does.
- Is that kind of idea crazy?
- Is there anyone who tried (or is going to try) something like that?
- Is L4-Linux going to keep up with the revisions of Linux in the
future?
You should not expect any real-time behavior if you use a L4Linux task to serve interrupts. Instead of this, implement the time-critical code (e.g. I/O to VME board, computations of output values) in an L4 task. Then let this task communicate with L4Linux by IPC (usually by using an own thread).
Then you will get worst-case latencies of about 85 microseconds (P800). Note that you should use the tamed version of L4Linux (make menuconfig - "L4Linux options" - "Use tamed server").
Frank
Hello,
On Friday 15 June 2001 8:49 PM, Frank Mehnert wrote:
You should not expect any real-time behavior if you use a L4Linux task to serve interrupts.
Here, you mean a "process of L4Linux" by the word "L4Linux task", wright?
Instead of this, implement the time-critical code (e.g. I/O to VME board, computations of output values) in an L4 task.
I'm aware that your suggestion is the right way. Still, it is convenient for me if a "process" can be used to serve interrupts in my application. I guess your "an L4 task" can be a "process" of L4-Linux if it has a priority higher than that of the Linux server task, am I wright? I noticed that a process can cause page faults even after it has called "mlockall" to make itself memory-resident. I've taken care of this.
Then let this task communicate with L4Linux by IPC (usually by using an own thread).
Then you will get worst-case latencies of about 85 microseconds (P800).
The worst-case interrupt latency I got was roughly 700 microseconds. What dominates the latency in L4-linux is not the performance of L4 (I'm using Fiasco, actually) but the critical sections of Linux, which are executed with disabling interrupts. RT-linux people found that standard Linux disables interrupts as long as 600 microseconds. It applies to the Linux server task of L4-Linux as well, I guess. I'm thinking of replaceing the "interrupts off" with another method to achieve required mutual exclusion. Then, I will get the number you suggested, hopefully.
Note that you should use the tamed version of L4Linux (make menuconfig - "L4Linux options" - "Use tamed server").
I'm going to check what the option does. Still, I was wondering if you could explain the point to me.
Jun-ichi
l4-hackers@os.inf.tu-dresden.de