Messages in this thread | | | Date | Fri, 11 Feb 2005 17:34:07 +1100 | From | Peter Williams <> | Subject | Re: 2.6.11-rc3-mm2 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |