Re: upcalls, timing and linux

Craig Milo Rogers (rogers@ISI.EDU)
Sat, 29 Aug 1998 03:01:10 -0700

>A few years ago, I was part of a project to add "scheduler
>activations" to Mach (see Usenix 1992 for the paper). Without getting
...
>I am currently working on a (music-related) user-level program that
>requires the best possible timing the OS can provide, much as the
...
>sequence of bytes cannot be known until the precise time actually
...
>I can see two possible solutions. One is to create a module that
...
>In my own
>particular case, in the bottom half of the timer interrupt, at the
>appropriate time, we'd upcall into my application, in effect asking
>"OK, tell me what to output at this point in time"; user level
>computation would result, and the answer would be passed back down as
>a pointer and a size; we'd copy the data over into kernel space and
>send it out the back door, so to speak. Voila, music timing as precise

Calling from the timer into a regular process sounds risky.
What if the user code page faults? What if it loops endlessly (you're
already in the timer BH, remember)? These issues could probably be
worked out (page locking, special timer faults, etc.), but...

The crucial issue is real-time response. Given that
constraint, it might be reasonable (depending upon other
characteristics of your application) to recode your application (or
its time-critical parts) as a loadable kernel module. Except for
whatever hooks (if any) it uses in more general code, your loadable
module won't be contributing to *everyone's* kernel bloat.

By the way, have ou considered implementing your time-critical
section(s) for RTLinux (Real-Time Linux)? This would seem like an
ideal application.

Craig Milo Rogers

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html