Hi!
On Wed, Aug 28, 2002 at 12:47:41PM -0400, rm wrote:
> which is still an issue. relying on the courtesy of user programs is
> probably not optimal (as i'm sure you're all well aware).
>
> [...]
>
> i've been working on a kernel patch that will allow a program to use
> the entire cpu up to some percentage of cycles which are reserved.
> (this is a common approach in RT literature). preliminary testing
> seems to indicate its workable, but a number of issues need to be
> cleared up (>1 cpu, what happens if more than one process wants fifo
> scheduling, etc). i will probably add a new scheduling policy,
> something like SCHED_USER_FIFO.
I am very interested in that. In all the discussions we had about the RT issue
in aRts, things usually came to the point: basically, it is a kernel bug, that
as soon as you use RT prio, your system becomes unstable. Especially if you
combine that with dynamically loaded modules, which even might be third party,
both approaches to work around the problem break.
1. if you try to write a monitoring system, then it is usually easy for the
dynamically loaded code to somehow kill or fool the monitoring system, or to
put it the other way round, it is hard to write a bullet-proof monitoring
system
2. if you try to audit all code that gets loaded and executed with RT prio,
and only load "trusted code", you're facing an endless task
What I thought might be interesting as well, once you have such a scheduling
policy, is a new ulimit that administrators can use to restrict RT prio on
their system to i.e. max 95% cpu usage - that way, they don't need to adress
all programs individually. That ulimit could even be there by default, so that
RT stability issues would disappear regardless of how programs used RT prio
in detail.
Cu... Stefan
--
-* Stefan Westerfeld, [EMAIL PROTECTED] (PGP!), Hamburg/Germany
KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
