Re: 2.6.11-rc3-mm2

[Peter Williams <pwil3058@bigpond.net.au>]

Nick Piggin wrote:
> On Thu, 2005-02-10 at 22:41 -0500, Paul Davis wrote:
> 
>>  [ the best solution is .... ]
>>
>>  [ my preferred solution is ... ]
>>
>>  [ it would be better if ... ]
>>
>>  [ this is a kludge and it should be done instead like ... ]
>>
>>did nobody read what andrew wrote and what JOQ pointed out?
>>
>>after weeks of debating this, no other conceptual solution emerged
>>that did not have at least as many problems as the RT LSM module, and
>>all other proposed solutions were also more invasive of other aspects
>>of kernel design and operations than RT LSM is.
>>
> 
> 
> Sure, it is quick and easy. Suits some. At least I do prefer
> this to altering the semantics of realtime scheduling.
> 
> I can't say much about it because I'm not putting my hand up to
> do anything. Just mentioning that rlimit would be better if not
> for the userspace side of the equation. I think most were already
> agreed on that point anyway though.

I think that the rlimits are a good idea in themselves but not as a 
solution to this problem.  I.e. having a RT CPU rate rlimit should not 
be a sufficient (or necessary for that matter) condition to change 
policy to SCHED_OTHER or SCHED_RR but could still be used to limit the 
possibility of lock out.  (But I guess even that is a violation of RT 
semantics?)

Peter
PS Zaphod's per task hard/soft CPU rate caps (which are the equivalent 
of an rlimit on CPU usage rate) are only enforced for SCHED_NORMAL tasks 
and should not (therefore) effect RT semantics.
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce