On Thu, 9 Jun 2005 08:29:21 +0200 asbjs(a)stud.ntnu.no (Asbjørn Sæbø) wrote: You can set certain threads to SCHED_FIFO with i.e. the chrt program from the schedutils package. But usually an app needs to be designed to use this scheduler class. BTW: SCHED_FIFO is not something which is only available in RP kernels. It's a POSIX specified scheduling class and its feature is that the scheduler will never take the cpu away from a SCHED_FIFO thread as long as [1] it doesn't give it up voluntarily [2] there's no other runnable SCHED_FIFO (or SCHED_RR) thread with higher priority. So a simple while(1) { //foo } that does never quit is enough to block all other processes from ever being executed (and thus seemingly hang your box). As i said this is not a feature exclusive to RP kernels, but you can do that even with a vanilla kernel. Normally non privileged processes cannot aquire SCHED_FIFO by themself. Thus people use the rtlimit or the realtime-lsm to grant these privileges to normal user programs. Ok, so what does the RP kernel do for realtime sensitive programs then? Basically two things: [1] decrease the length of non preemptible code paths in the kernel by making practically everything preemptible. This reduces the time it takes, for example, to run a SCHED_FIFO thread after the interrupt it waits for has happened (if it's the highest priority runnable thread in the system the maximum delay experienced from non preemptible code paths in a RP kernel is in the microseconds range). [2] split the interrupt handling routines into a new top level handler which is very very short and a handler thread that runs SCHED_FIFO with a certain priority (which can be user changed). With this you can give priorities to your interrupts i.e. if you want that your soundcard irq shall be handled with the highermost priority in the system set its irq handler priority to something higher than all other IRQ handler threads and processes in your system. A typical jack setup on a RP system usually looks like this: keyboard irq: 99 (to get to magic sysrq in the case of an emergency) rtc irq: 98 (used for midi timing in some applications) soundcard irq: 97 jackd prio: 70 (its watchdog will run prio 80 then) all other irq's and processes below 70. i usually leave them at the defaults around 50. This way any disk activity can never disturb the soundcard operation. btw: i don't know if all this info helps you at all. Why don't you tell us a bit more about your problem domain and we can try to figure out how/if RP kernels can help you with it.. -- Palimm Palimm! http://affenbande.org/~tapas/

asbjs(a)stud.ntnu.no (Asbjørn Sæbø) writes: Sounds reasonable. It's possible that the "rewrite" might not be all that major. Setting the scheduling class for a thread is fairly easy. Making sure it doesn't call any non-realtime-safe system services is harder. If you need to read or write a log file on disk, you'll almost certainly need a multithread solution similar to what we do for audio capture or playback. Disk I/O is definitely *not* a realtime-safe operation. -- joq

Martin Habets <errandir_news(a)mph.eclipse.co.uk> writes: To clarify: there *was* an experimental patch like this created six months ago, but it is not widely available. The rtlimits patch in the -mm kernels only limits the SCHED_FIFO priority available to certain users or groups. It does *not* limit the amount of time they can consume. If you want to guard against CPU starvation, you'll need some kind of watchdog thread. JACK has one for it's own clients, but not a general solution. -- joq