Messages in this thread | | | Date | Sat, 11 Jun 2005 01:29:55 +0200 | From | Andrea Arcangeli <> | Subject | Re: Attempted summary of "RT patch acceptance" thread |
| |
On Fri, Jun 10, 2005 at 04:08:36PM -0700, Bill Huey wrote: > On Sat, Jun 11, 2005 at 12:52:31AM +0200, Andrea Arcangeli wrote: > > Just tell me how can you go to a customer and tell him that your > > linux-RTOS has a guaranteed worst case latency of 50usec. How can you > > tell that? Did you exercise all possible scheduler paths with cache > > disabled and calculated the worst case latency with rdtsc + math? > > Ask Ingo. I'm through with this track and your misinformed comments
You didn't provide an answer yourself, and you fallback on somebody else cause there's no valid answer to this question. All I've seen so far are measurements backed by some statistical significance, that's very far from the meaning I give to the word _guarantee_.
I fully acknowledge there are some problems that aren't more equally easily solved with full userland code, for those problems keeping things simpler by making the kernel more RT aware has a value.
I fully acknowledge that simulating infinite cpus has a value too in discovering race conditions too ;).
But I personally dislike all things that works by luck, preempt-RT that aims to provide guarantees about worst case latencies is no exception, so you shoudln't be surprised if I'm not a RTOS backer for problems that can be more easily solved with ruby-hard RT designs like RTAI and rtlinux. I don't care how things have worked in the past on non-linux OS. Most of the time even current not-RT linux will work fine if it's idle as it would be on some embedded usages like the printer example.
This even ignoring the fact all those context switch will not be cheap, kernel can execute a lot more hard-irqs than context switches per second, and this is another fact. On a 4ghz cpu it doesn't matter, but on a embedded it can matter, so the more reliable solution is obviously higher performant too. Of the 50usec it takes to such project on linuxdevices to execute probably a 10% of that is wasted in the irq handling itself (ioapic hardware proper stuff).
Anyway I've more fun things to do on than to talk about hard-RT, which I'm doing just with the aim to provide my little contribution in form of IMHO valid criticism that you clearly don't appreciate. - 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/
| |