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