lkml.org 
[lkml]   [2004]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [ANNOUNCE] Linux 2.6 Real Time Kernel
    From
    Date
    On Sat, 2004-10-09 at 16:11, Karim Yaghmour wrote:
    > Lee Revell wrote:
    > > Yes. The upper bound on the response time of an RT task is a function
    > > of the longest non-preemptible code path in the kernel. Currently this
    > > is the processing of a single packet by netif_receive_skb.
    >
    > And this has been demonstrated mathematically/algorithmically to be
    > true 100% of the time, regardless of the load and the driver set? IOW,
    > if I was building an automated industrial saw (based on a VP+IRQ-thread
    > kernel or a combination of the above-mentioned agregate) with a
    > safety mechanism that depended on the kernel's responsivness to
    > outside events to avoid bodily harm, would you be willing to put your
    > hand beneath it?
    >

    In theory, I think yes, if all IRQs on the system run in threads except
    the saw interrupt, and the RT task that controls the saw runs at a
    higher priority than all the IRQ threads. You can guarantee that other
    interrupts won't delay the saw, because the saw irq is the only thing on
    the system that runs in interrupt context. With the current VP
    implementation you are still bounded by the longest non-preemptible code
    path in the kernel AKA the longest time that a spinlock is held.
    Replacing most spinlocks with mutexes reduces this to less than 20 code
    paths according to Mvista, which then can be individually audited for
    RT-safeness.

    That being said, no way would I put my hand under the saw with the
    current implementation. But, unless I am missing something, it seems
    like this kind of determinism is possible with the Mvista design.

    > How about things like a hard-rt deterministic nanosleep() 100% of the
    > time with RTAI/fusion?

    I will check that out, I have not looked at RTAI in over a year.

    Lee

    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 14:06    [W:4.096 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site