Re: 2.6.11-rc3-mm2

[Peter Williams]

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@xxxxxxxxxxxxxx

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/