Messages in this thread | | | Subject | Re: [PATCH] [request for inclusion] Realtime LSM | From | "Jack O'Quin" <> | Date | Tue, 11 Jan 2005 13:42:33 -0600 |
| |
> On Tue, Jan 11, 2005 at 08:05:08AM -0500, Paul Davis wrote: >> I am not sure what you mean here. I think we've established that >> SCHED_OTHER cannot be made adequate for realtime audio work. Its >> intended purpose (timesharing the machine in ways that should >> generally benefit tasks that don't do a lot and/or are dominated by >> user interaction, thus rendering the machine apparently responsive) is >> really at odds with what we need.
Matt Mackall <mpm@selenic.com> writes: > We have not established that at all. In principle, because SCHED_OTHER > tasks running at full priority lie on the boundary between SCHED_OTHER > and SCHED_FIFO, they can be made to run arbitrarily close to the > performance of tasks in SCHED_FIFO. With the upside that they won't be > able to deadlock the machine. > > And I mean arbitrarily close in the strict delta-epsilon sense. > It's not perfect, but neither is SCHED_FIFO, in principle or in > practice.
Though inelegant in theory, SCHED_FIFO *has* been shown to work in practice. The POSIX 1003.4 committee were not all a bunch of idiots. That stuff *is* useful and *does* work (given appropriate privileges).
Your assertions have not been reduced to practice. This is a significant difference. Write some code, then we can discuss whether it solves any problems or not. I doubt it, but prove me wrong and next year you can be the proud author of a scheduler used for hundreds of audio applications.
Meanwhile, what about 2005? It's "almost upon us". :-/ -- joq - 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/
| |