Messages in this thread | | | Date | Sat, 29 Aug 1998 02:04:19 -0400 | From | Paul Barton-Davis <> | Subject | upcalls, timing and linux |
| |
A few years ago, I was part of a project to add "scheduler activations" to Mach (see Usenix 1992 for the paper). Without getting into the scheduler/thread/user/kernel aspects of this idea, part of the stuff we did was to provide a new mechanism for the kernel to "upcall" into user space, somewhat analogous to the signal mechanism, but implemented quite separately. Essentially, the kernel says "you asked me to tell you when X happened, and it has, so do whatever you wanted to do and get back to me". In our case, "X" was stuff like a page fault or a disk wait.
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
| |