I am currently working on a (music-related) user-level program that
requires the best possible timing the OS can provide, much as the
amiga and the mac have done for some time. What I essentially want to
have happen is for a certain (short) byte stream to be written to a
given device at a precise time. The current HZ=100 convention provides
enough resolution.
Ordinarily, this would be easy to do. However, in this case, the
sequence of bytes cannot be known until the precise time actually
arrives. It is therefore impossible to simply download the byte stream
to the kernel ahead of time - it isn't known. Using user-level signals
(i.e. SIGALRM) simply isn't accurate enough for this purpose (its what
I do now, and its unreliable in the face of disk activity and/or
sudden load bursts).
I can see two possible solutions. One is to create a module that
implements the computation needed to decide which bytes to emit, and
stick it in the kernel. This has the consequence of using the kernel
to implement policy, rather than mechanism, and I'm opposed to it for
every reason except that it would be easy.
However, going back to the upcalls in Mach, it occurs to me that there
could be a more generic solution here that might be useful in other
contexts. The idea would be to provide the kernel with a way to "ask"
user level what it should do. The interface would be fairly generic,
allowing the "answer" to be a scalar or pointer value. 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
and reliable as that found on earlier, single-tasking systems. Well,
almost :) Note that the kernel preemption guarantees that linux so
wisely provides would be preserved while the upcall executes.
Upcalls implementing scheduler activations provided some real gains
for multithreaded programs on MP platforms. It seems obvious that in
this model, no such gain is offered, and in fact, upcalling into user
space in this way is clearly slower than doing the work entirely in
kernel space. The beauty of the Linux module system does make me
wonder if there's really anything wrong with kernel-side policy, but I
still have a feeling that upcalls might be useful for other things.
Although I could implement this stuff for Linux pretty quickly, I thought
I'd ask first if anyone has any thoughts on whether this is actually
worthwile for any other contexts that the example I'm working on.
--thanks
--pbd
-
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