Re: [PATCH] [request for inclusion] Realtime LSM

[Con Kolivas <kernel@kolivas.org>]

[-- Attachment #1: Type: text/plain, Size: 3954 bytes --]

Matt Mackall wrote:
> On Fri, Jan 14, 2005 at 11:50:14AM +1100, Con Kolivas wrote:
> 
>>Jack O'Quin wrote:
>>
>>>Arjan van de Ven <arjanv@redhat.com> 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
> 
> 
> This sounds promising, but I think it still needs to be privileged.
> See a) below.

>>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).
> 
> 
> a) How to arbitrate between competing unprivileged users that want
> pseudo-SCHED_FIFO? Do they all lose?
> b) Priority levels are important here, we want to be able to do things
> like have audio run at higher priority than video.

Indeed how OSX does it is to pretend that it is paying any attention at 
all to the QoS requests that is given to it. In actual fact all it does 
is RR frequently enough and then everything tends to work anyway...

The reason I suggest not supporting priorities (at the moment) is for 
them to even work I would need to implement a complete Earliest Deadline 
First scheduler, ideally with more syscalls and transferring QoS 
requests to the scheduler. This is umm non-trivial to say the least... 
but possible on a landscape not living in a 2.6 forever development world.

Cheers,
Con

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]