Messages in this thread | | | Date | Fri, 14 Jan 2005 18:20:35 +0100 | From | Mike Galbraith <> | Subject | Re: [PATCH] [request for inclusion] Realtime LSM |
| |
At 05:31 PM 1/13/2005 -0600, 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 for one wonder why that appears to be so. What happens if you use SCHED_RR instead of SCHED_FIFO?
(ie is the problem just one of running out of slice at a bad time, or is it the dynamic priority adjustment)
-Mike
- 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/
| |