Messages in this thread | | | Subject | Re: a joint letter on low latency and Linux | Date | Sat, 01 Jul 2000 21:02:44 -0400 | From | Paul Barton-Davis <> |
| |
>I don't know what a "specifically RT technique" is and I don't care >how its done -- if the kernel can promise to always respond to an interrupt >within some bound, then the kernel offers a hard realtime guarantee. >And, for what it's worth, my professional opinion is that this is incredibly >hard to do and never worth doing in a kernel that also wants to offer >high speed networking, files systems, and guis.
I fully respect your opinion (both professional and otherwise) about how hard it is to do.
However, I think it would also be an incredibly great thing to do (i.e. totally worth doing) if it were really possible to accomplish it in the context of Linux' many other strengths. This is precisely where BeOS, for example, falls down: phenomenal scheduling response, but poorer support for all the other good stuff that Linux folk are used to.
>I'm sure Ingo will tell you that his patch is designed to make long >latencies _rare_ not impossible.
And as I've said, one dropout every few days is fine with almost everyone. There's very little equipment in the studio I work in that doesn't have some kind of hiccup like that.
>Goal A: > I want low latency Linux where typical interrupt response time is > under K ms and violations are rare -- usually no more than one > every T hours under such and such a load. > >Goal B: > I want hard realtime guarantees in Linux, but I don't need a full > realtime operating system, just promise my application's hard > realtime requirement is met. > >In my humble opinion: Goal A is great, Goal B is horrible.
Goal A is my goal. Goal B is "a bunch of crap" as various participants here would put it.
>> The only subset that has to be RT safe is scheduling. The rest is not >> part of the central issue here. > >Paul: don't use the word "only" to describe hard realtime scheduling. >That's the absolute heart of hard realtime.
OK, so Victor: is it your considered, humble and professional opinion that it would be impossible to offer, lets say, 1 failure per 4 hours of a 2ms interrupt-driven reschedule response time without implementing "full hard real-time" in the kernel ?
Suppose that we add a couple of assumptions:
* the only threads that matter are SCHED_FIFO * those threads run in mlockall() address spaces (i.e. no paging of any part of their address space) * the number of other runnable threads never rises above N
Do such assumptions make it any easier ? This is important, because in many of the situations where audio/MIDI folk would be using this stuff, these (or similar) assumptions are easy to meet.
>> but i continue to maintain that because the audio thread in these apps >> can be reduced a purely computational process, with no memory, i/o or >> other system resource issues, it can be solved (not that it *should* >> be solved this way, but it can be) by using a fully-preemptable kernel >> that does not satisfy most of the requirements of an RTOS. > >And I continue to believe that a fully-preemptable general >purpose kernel is like a microkernel -- a delightful theoretical concept >that has been shown by repeated experiment to be a horrible >practical experience.
No dispute here. That wasn't my point. I was trying to point out that contrary to some of the claims here, it seems possible to me to solve this without creating an RTOS. I don't think anybody would consider IRIX an RTOS, but my understanding is that it can offer scheduling responses on the order of what we are talking about here.
Again, I am not advocating a fully-preemptable approach. Larry and other IRIX folk have made the pain of that development effort very clear, as well as the costs. Its more that I want to try to flush out the different ways to accomplish the same thing. Larry has claimed that you couldn't get the performance we need without either
1) making Linux into something very RTLinux-like, OR 2) adding preemption points all over the place
If (1) is the only alternative to (2), I would be happy, as I said before, to take on some level of responsibility for organizing, or helping to organize, the maintainance and development of Ingo's patches so that low-latency requiring people can use solution (2) on more or less any kernel.
The other notable player in all this, of course, is MontaVista. However, since they don't seem terribly concerned about getting their work into the mainstream kernel, its not clear that its that relevant to the problem at hand.
--p
Of course, technological changes and a smart >person or 10 may prove me to be wrong, but it's not the kind of >experiment that would be good to try with the main development tree >of a production kernel. > > >> >> --p >> >> - >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majordomo@vger.rutgers.edu >> Please read the FAQ at http://www.tux.org/lkml/ > >-- >--------------------------------------------------------- >Victor Yodaiken >FSMLabs: www.fsmlabs.com www.rtlinux.com >FSMLabs is a servicemark and a service of >VJY Associates L.L.C, New Mexico. > >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |