Messages in this thread |  | | | Date | Mon, 30 May 2005 21:25:02 +1000 | | From | Nick Piggin <> | | Subject | Re: RT patch acceptance |
| |
Nick Piggin wrote: > Bill Huey (hui) wrote:
>> >> Uh, not really. Have you looked at the patch or are you inserting >> hysteria in the discussion again ? :) Sounds like hysteria. >> > > OK, I'll start small. What have you done with the tasklist lock? > How did you make signal delivery time deterministic? > > How about fork/clone? Or don't those need to be realtime? What > exactly _do_ you need to be realtime? I'm not asking rhetorical > questions here. >
Let me ask another question while you're thinking about that. Note, this is a *specific* question that can easily be answered without waffling about XFS or telling me to start writing RT media apps, or accusing me of spreading hysteria...
OK:
I think it has been conceeded that a realtime Linux kernel cannot be enabled by default because of prohibitive overhead, right? I think this is even the case for PREEMPT_RT, which is not hard-RT. (Correct me if I'm wrong).
Suppose you had a system where you need some RT operations, but cannot tolerate such overhead for general purpose performance processing.
So by definition you have excluded a single kernel approach. A nanokernel is not clearly excluded. In fact, maybe it is possible to run the Linux image with little overhead? Maybe almost none with the right CPU hardware? (correct me...)
If you get to here without correcting me, my question is: does such an application exist? Silly example is a cell phone + JVM, but something really interrupt heavy (and maybe SMP as well) might be better to cripple PREEMPT_RT.
Thanks. I can think of some other specific questions too, when you've addressed these. Send instant messages to your online friends http://au.messenger.yahoo.com
- 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/
|  |