Re: Attempted summary of "RT patch acceptance" thread

[Andrea Arcangeli <andrea@suse.de>]

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/