[rtl] kernel scheduler hack

[steve rosenbluth <stever@la.creatureshop.henson.com>]

Can anyone offer some insight into the problem (attached).

It would be real nice if RTlinux could force the kernel scheduler to run
tasks blocking on a rt-fifo device, then we could have soft real time in
linux as well as hard real time from the rt-executive.

-- 
Steve Rosenbluth
Jim Henson's Creature Shop
2821 Burton St, Burbank CA
(818) 953-3030
Hello, I wonder whether you can answer a Linux kernel scheduling
question.

We have hit a problem which we can't seem to solve without kernel
hacking, and I'm not familiar enough with the kernel scheduler to know
whether the hack would work if we did do it. We're using 2.0.35 .

The problem:
The goal is to have my linux process, the "engine", invoked at a regular
interval (60 times per second). We are successfully using a Real-Time
Linux periodic task to produce an IO byte on a device called
/dev/framrate at 60 Hz. I made the "engine" block on a read of this
device until a byte came in, then run.  Unfortunately, the kernel is not
scheduling my "engine", even when there is data in the device, when
another demanding process is running.  Examples of demanding processes
are: dragging an Xterm with the mouse, or running a 'find' command.

I have tried telling the kernel to give my engine highest priority via
the sched_setscheduler() call. This does appear to insure that the
engine is not preempted by other tasks once it is running.  It does not,
however, sufficiently raise the initial scheduling priority of the
engine - the engine is invoked late, long after the device it is
blocking on has data, due to concurrent processes.

These findings have been viewed and measured on an oscilloscope (I'm
outb()-ing a pulse to the printer port when the motion engine is
invoked).

Note: we don't want to move the engine into kernel space as a device
driver, or into RT-Linux.  This is because we wanted to use Linux
serial drivers, pipes, etc. from within the engine (and we wanted to use
C++ and memory management).


The Kernel Hack Questions:

1. Can we rewrite the scheduler to always try the "engine" task, say,
every second time slice ?  I imagine this would mean somehow registering
my desired task with the scheduler at run time.  The "engine" could do a
non-blocking read in this case, and if it wasn't ready to run yet, do a
sched_yield().

2. Is it possible that the interfering tasks (like X) are actually
spending so much time in kernel space that there is no way a change in
the scheduling algorithm will ever guarantee my process gets invoked at
a high enough frequency ?


I have read of KURT, UTIME, MARUTI, and the "QNX" scheduler, but the
thought of trying to integrate those patches the RTlinux patched
kernel is scary. (we're committed to RTlinux because of a device
driver).

This project is very machine specific, ie: we can't change to different
hardware.  We are using a P-II 266Mhz Laptop, k2.0.35 w/ RTlinux patch,
libc6, Xfree86 on a TFT screen, ide hard drive, 192 MB RAM.

This is a commercial project and we are under time and cost pressures.
Thank you for any information you can provide.