Bernd Petrovitsch wrote: > On Fri, 2005-08-05 at 11:28 +0200, Thomas Petazzoni wrote: >>However, the kernel is not fully preemptive: there are some portions of > > > And never will be if you mean "fully preemptive" similar to "preemptive > processes in the user-space" where the preemption may happen (almost) > before every assembler instruction. > > >>code during which preemption is disabled (using preempt_disable() and >>preempt_enable()), and real-time people are trying to get rid of these >>portions of code (or at least reduce them), in order to get the lowest >>possible latencies. > > > The real-time people use RTAI and don't really care about the rest of > the Linux kernel. Or do you mean the low-latency folks? There is also Ingo Molnar's (and probably others') RT-PREEMPT patches currenty under development. These really do try to get nearly every point preemtible. Drivers should synchronise with semaphores, mutexes (which both do priority inheritance), and completions. Preemption should then only be disabled when hardware has a very strict timing that requires busy waiting, during scheduling and possibly locking. Furthermore, IRQ handlers become threaded (as an option) and thus pre-emptible, except for the system timer, and can be given realtime scheduling priorities. As an example, the system timer is the highest priority (I think, as it cannot be threaded), and you could have the sound card interrupt at the second highest priority, then jackd (a userspace realtime audio daemon) at the third highest priority. jackd will grant realtime behaviour to a user's process for a limited time (it has a watchdog to revoke that to avoid starvation of other processes). This helps ensure that audio *never* skips, for professional audio performances and the like. -- Tristan Wibberley Opinions expressed are my own and do not necessarily coincide with those of my employer, etc. -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
