> Its still a mystery why a process in linux-user-space which gets
> scheduled out doesn't come back for two timeslices. Does anyone
> understand the Linux kernel scheduler well enough to explain that ?
> try the code I posted yesterday.
I'm sorry I didn't save your code. If I remember it right, you were
using the scope to physically measure the timeslicing. I suppose you are
talking about the regular Linux kernel and not the RT Linux one.
I performed a test of my own and could not reproduce your symptom. I had
only one active user process and it got ~100% of the CPU. Here's what I
did:
====BEGIN PROGRAM=======================================================
#include <stdio.h>
#include <sys/time.h>
void main(int argc,const char *const argv[])
{
struct timeval t0,t1;
if (argc != 2) exit(1);
gettimeofday(&t0,0);
asm("movl %0,%%ecx; myloop: decl %%ecx; jnz myloop"
:: "g"(atoi(argv[1])) : "ecx");
gettimeofday(&t1,0);
printf("%d\n",(t1.tv_sec - t0.tv_sec) * 1000000 + t1.tv_usec - t0.tv_usec);
exit(0);
}
====END PROGRAM=========================================================
The asm command is a simple tight loop. Despite consisting of two
instructions, my Pentium seems to execute it in a single clock cycle.
When I ran the program under the regular 2.0.36 kernel, the result was
consistently and very accurately 4.301 ns/loop for large loop counts
(try 0). Since my clock rate is 233MHz, one clock cycle is 4.292 ns. In
other words, the interrupt overhead is only 9/4,292 or 0.2%.
When I run two instances of the program in parallel, I get exactly half
the performance (per process).
In other words, the active processes get virtually all of the CPU
bandwidth as they should.
> 2. linux-user-space, soft-real-time, variable length motion control
> calc's
This is very risky especially if you don't control all of the software
running in the system. The user processes may be switched out literally
for seconds. At least you must make your process high-priority and
sticky so your process doesn't need to worry about page faults.
Here's an anecdote: My brother made his master's thesis in robotics. He
used a regular SunOS workstation to control a robot's arm. It worked ok
most of the time, but every once in a while the heavy arm banged to one
of the extreme positions. I'm glad nobody was killed. The reason was
unexpected latencies in the system in the range of 100ms despite the
fact that the control software was made sticky and had the highest
priority, and nothing else was supposed to be running except some
daemons.)
So I recommend keeping _all_ critical RT calculations on the RT side.
> The very first approach I tried was to create a linux-user-space process
> which blocks on a RTfifo, a RT periodic task sent a word down the fifo
> at 60 Hz. This did NOT work well. The linux task was invoked irregularly
> depending on what other processes and IO were happening concurrently.
Exactly.
Marko
--
Marko Rauhamaa [EMAIL PROTECTED] (818) 878-6314
Sr Project Engineer http://www.tekelec.com/ Tekelec Inc
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
