Re: [PATCH] [request for inclusion] Realtime LSM
From: Con Kolivas
Date: Thu Jan 13 2005 - 20:00:23 EST
Jack O'Quin wrote:
Arjan van de Ven <arjanv@xxxxxxxxxx> writes:
On Thu, Jan 13, 2005 at 04:25:08PM -0500, Lee Revell wrote:
The basic issue is that the current semantics of SCHED_FIFO seem make
the deadlock/data corruption due to runaway RT thread issue difficult.
The obvious solution is a new scheduling class equivalent to SCHED_FIFO
but with a mechanism for the kernel to demote the offending thread to
SCHED_OTHER in an emergency.
and this is getting really close to the original "counter proposal" to the
LSM module that was basically "lets make lower nice limit an rlimit, and
have -20 mean "basically FIFO" *if* the task behaves itself".
Yes. However, my tests have so far shown a need for "actual FIFO as
long as the task behaves itself."
I should comment on this thread on lkml. After some
investigation/discussion and testing I came up with a proposal for this
problem. Since we are a general purpose operating system and not a hard
rt system (although addon patches are clearly making that a future
possibility) we need a solution that is satisfactory to a general...
There are two ways I suggested for this.
First, (and I am increasingly believing in the second) is to implement a
new scheduling class for isochronous scheduling. This would be a class
for unprivileged users, and behave like SCHED_RR (to avoid complications
of QoS features we dont have infrastrucutre for) at a priority just
above SCHED_NORMAL, but below all privileged SCHED_RR and SCHED_FIFO.
Importantly, a soft cpu limit and rate period can be set by default for
this scheduling class that provides good true SCHED_RR performance, and
is configurable. Literature suggests that 70% is adequate cpu for good
real time performance and would be starvation free. I believe setting
70% with 10% hysteresis (dropping to say 63% on hitting limit) would be
a good start. Beyond this, however, to satisfy the needs of those with
more demanding setups, a simple configurable runtime setting to set both
the cpu% and the rate period could be available to something as simple
as proc
/proc/sys/kernel/iso_cpu
/proc/sys/kernel/iso_cpu_period
where iso_cpu is set to 70, and period to maybe 1 second. The actual
mode of setting this tunable is not important, and could be in /sys or
whatever
The second option is to not implement a new scheduling class at all, and
allow unprivileged users to use either SCHED_FIFO or SCHED_RR, but to
make the cpu constraints described for SCHED_ISO above apply to their
use of those classes. Supporting priority settings for these could be
possible, but in my opinion, it would work as a better class if they
only had one priority level, as for the SCHED_ISO implementation above
(better than any SCHED_NORMAL, but lower than privileged SCHED_RR/FIFO).
This latter approach to me seems the least invasive and most user and
sysadmin friendly method.
What was amusing to me was that after I suggested the latter option, I
discovered that was basically what OSX does, however being not a real
multi-user operating system they had absurd limits for cpu at 90% by
default. Theory suggests 70% should be a good default limit.
Cheers,
Con
Attachment:
signature.asc
Description: OpenPGP digital signature