Thu, 23 Mar 2000 Kulwinder Atwal wrote:
> David Olofson wrote:
> >
> > Wed, 22 Mar 2000 [EMAIL PROTECTED] wrote:
> > > (BTW: from the Linux man page:
> > > As SCHED_FIFO and SCHED_RR processes can preempt
> > > other processes forever, only root processes are allowed to activate these
> > > policies under Linux.
> > > )
> >
> > Yep, you have to have *some* kind of adrenaline rush left with protected memory
> > and all! ;-) If you want to be completely safe, you could always throw in a
> > watchdog thread or something...
>
> The watchdog thread would be preempted as well. If Linux does
> SCHED_FIFO and SCHED_RR by turning off interrupts, then even setting a
> timer interrupt will not work. The only option may be to have a
> hardware COP watchdog card in the PC.
AFAIK, the only important difference in this regard is that no normal (lower
priority) tasks can preempt the real time threads. If you have the watchdog
thread run at highest priority + SCHED_FIFO, and sleep on some suitable kernel
driver (like RTC, unless you need it for other things), it should preempt the
real time threads as desired. As for disabling interrupts; SCHED_FIFO and
SCHED_RR threads cannot freeze the kernel, "only" all user space threads, so
this is not the case.
> I was thinking Magic SysRq key to kill the
> > current (SCHED_FIFO or SCHED_RR) thread as another alternative, but I might be
> > missing something that already exists.
> >
> > And as for the root privileges requirement, it has been discussed adding a
> > "real time" user group capability instead. (I'm not up to date with this,
> > though.) Running RT apps as root just for the scheduling is not all that nice in
> > production systems, especially not if they are going to run user installed
> > third-party plugins in those threads...
>
> Only your scheduler has to be root. Your scheduler is responsible for
> changing the policy for a process. Only that process will have its
> policy changed.
Having to throw in some "system real time manager" means enough trouble to
complicate things too much for the average user. The "production systems" I'm
thinking of are standard installs of various distros, and the real time
capabilities will be used by ordinary applications with real time engine
threads. Also, a solution of the kind "RT manager" would be a security
problem (any app can freeze the machine), unless access to the RT manager is
restricted along the lines of an RT group.
> Any processes that your scheduler controls can be in
> user space.
Uhm, yes we're dealing only with user space and the standard Linux scheduler
here. (I think I'm missing your point...)
No special kernel support is needed, provided the lowlatency patch gets in.
(The non-preemptive version, that is - Linus strongly disliked the one that
enabled preemption during some "lengthy" operations.) The RTC supports async
signals as of some 2.3.x kernel, so you don't have to use a sound card (or
whatever) as time base.
> Read the man page for sched_setscheduler.
Speaking of which, this page also describes how SCHED_FIFO and SCHED_RR is
handled. :-) There is nothing more to it, and the lowlatency patch doesn't
change anything but the scheduling jitter.
Regards,
//David
P r o f e s s i o n a l L i n u x A u d i o
· ··-------------------------------------------------·· ·
MuCoS - http://www.linuxdj.com/mucos
Audiality - http://www.angelfire.com/or/audiality
David Olofson - [EMAIL PROTECTED]
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
