On Sat, 9 Oct 1999, James Simmons wrote:
>
> > IIRC, IRIX and AIX do just that. It is a specialized type of hard
> > realtime guaranteed scheduling for the display and console subsystems. And
> > regular kernel semaphores are not going to be able to give you hard realtime
> > guarantees. The whole display and console system needs to be:
> >
> > * Able to trap freely at the interrupt and fault level and hold off the
> > scheduler for an arbitrary period of time;
>
> RTlinux can do that. This is needed to make sure data is transfered full
> to the accel engine for each accel command. You could confuss the accel
> engine otherwise. The way RTLinux works is it reprograms the clock to go
> off at specific times. RTLinux works better on SMP machine than UMP
> becuase the special clock is need to handle SMP motherboards. Also the
> rtl_schedular is the main function of the kernel. The regular schedular is
> called when the rt_schedular is idle. You can set the rtl_schedular to be
> periodic.
>
> > * Able to schedule down arbitrary processes in the presence of hardware FIFO
> > watermark violations, and to directly program the same FIFOs;
>
> This would have to be added. I see from RTLinux it depends heavly on
> FIFOs. What are FIFO watermark violations?
Often, hardware (like video hardware) which must handle command FIFOs
will provide settable high/low watermark values, which will either fip a
status bit or fire an interrupt when the number of commands in the hardware
FIFO goes above the high watermark or below the low one. This allows you to
"balance" the hardware command FIFO against the software command FIFO which
is feeding the hardware. What you do not want to have happen is a hardware
FIFO over-run (can cause expensive software blocking until the FIFO is
sufficiently drained) or under-run (the hardware will sit idle waiting for
new commands to enter the FIFO, thus possibly causing flickering or framerate
loss in streaming video, etc).
Good hardware these days also has settable timeout warnings for
asynchronous hardware events - z-test, texture read/write, DMA transfer, and
many other types of internal hardware events. These settable timeout values
also assist in balancing the hardware to ensure quality-of-service
guarantees.
> > * Able to extend these guarantees to userspace in clean, well-defined
> > abstractions.
>
> Hum. Explain what you have in mind.
As with any limited hardware resource, the kernel should make it
available to userspace code to allocate (if available) and use, so that the
device drivers can handle these hardware features in a more generic way, and
possibly register userspace callback hooks as well. So, for example, the
driver might not have to know that you are watching TV in a window - it just
knows that some bit of user code requested a particular region-to-resource
mapping at a particular resolution and framerate.
Now, it may be quite easy for the hardware to maintain that
framerate, so this process' FIFO watermark, timeout, etc settings would not
have to be very extreme at all, and the kernel would be able to schedule the
process less often and still keep the framerate up. But if Quake3 is being
played in another window, its demands on the hardware will probably be quite
a bit more extreme, and so the userspace Quake3 process will need to request
more time-invariant resource guarantees from the hardware.
> Well I have joined the RT linux team and I'm studing their code. Do you
> really think going RT linux is the way to go?
I cannot see any way in which it could be worse, but be prepared for
some crazy hacking I'm sure |->.
> The big thing always thrown
> in my face is performace. If we can design a safe accel system that can
> outperform DRI we got it made >:->
I think we can outperform DRI in regular Linux anyway.
> Note:
>
> When you switch the kernel to RT mode the regular schedular does not
> work as effiecently.
Sure. The RTLinux kernel runs Linux as its idle task, IIRC.
> Since RT process take far greater precedence the
> other process suffer a preformance hit. Of course while playing Quake 3 I
> don't think the average use will be worring that syslogd is not running
> as often as it was before.
If the video driver, input drivers and console subsystem were in
RTLinux, Linux itself would have very little to do that was at all
time-critical.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
