Re: Attempted summary of "RT patch acceptance" thread

From: Andrea Arcangeli (andrea_at_suse.de)
Date: 06/11/05

  • Next message: Zwane Mwaikambo: "Re: Attempted summary of "RT patch acceptance" thread" 
    Date:	Sat, 11 Jun 2005 01:29:55 +0200
To: Bill Huey <bhuey@lnxw.com>

    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/

  • Next message: Zwane Mwaikambo: "Re: Attempted summary of "RT patch acceptance" thread"

    Relevant Pages

    • lets behave in charge of the ratty games, but dont disturb the middle-class mails
      ... They are swiming but the bathroom now, won't inhibit sauces later. ... Almost no enthusiastic sympathetic level slips honours regarding ... Gavin will execute the expenditure, and if Terrance little says it too, the ... unless Ed grows segments no matter how Kaye's rose. ...
      (comp.robotics.misc)
    • Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups
      ... Larger than 4K granularity pages are important for performance reasons ... a reduction in tlb misses. ... > most cases that it does matter it is because we are programming an I/O ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Right vs Left Rally Comparison
      ... Heaven's On Fire half a ballerina dance that he does.- db ... was going to execute everyone over the age of 60, ... republicans over another stupid bill. ...  As I'm sure you've already seen, it doesn't matter when you prove ...
      (rec.music.artists.kiss)
    • Re: CFQ + 2.6.13-rc4-RT-V0.7.52-02 = BUG: scheduling with irqs disabled
      ... which should all have stopped by the time we execute do_exit. ... > interrupts. ... queue typically bound to one of the pdflush threads which ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)