lkml.org 
[lkml]   [2004]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch

    * Scott Wood <scott@timesys.com> wrote:

    > > if both hardirqs and softirqs are redirectable to process contexts then
    > > the only unpredictable latency would be the very short IRQ entry stub of
    > > a new hardirq costing ~5 usecs - which latency is limited in effect
    > > unless the CPU is hopelessly bombarded with interrupts.
    >
    > Those aren't the only sources; you also have preempt_disable() and
    > such (as well as hardware weirdness, though there's not much we can do
    > about that).

    i did not say latency sources, i said unpredictable latency sources.
    hardirq and softirq processing introduces near arbitrary latency at any
    (irqs-enabled) point in the kernel. Hence they make all kernel code
    unbound in essence - even the most trivial kernel code, sys_getpid().

    by (optionally) moving softirqs and hardirqs to a process context we've
    removed this source of uncertainty by making all processing synchronous,
    and what remains are ordinary algorithmic properties of the kernel code
    - which we can predict and control. I.e. with those two fixed we now
    have a _chance_ to guarantee latencies.

    [the only remaining source of 'latency uncertainty' is the small
    asynchronous hardirq stub that would still remain. This has an effect
    that can be compared to e.g. cache effects and it cannot become unbound
    unless the CPU is bombarded with a very high number of interrupts.]

    > > to solve the spinlock problem of hardirqs i'd propose a dual type
    > > spinlock that is a spinlock if hardirqs are immediate (synchronous) and
    > > it would be a mutex if hardirqs are redirected (asynchronous). Then some
    > > simple driver could be converted to this RT-aware spinlock and we'd see
    > > how well it works. Have you done experiments in this direction?
    >
    > This sort of substitution is what we did in 2.4, though we made this
    > type the default and gave the real spinlocks a new name to be used in
    > those few places where it was really needed. Of course, this resulted
    > in a lot of places using a mutex where a spinlock would have been
    > fine.

    what are those few places where a spinlock was really needed?

    I'm a bit uneasy about making mutexes the default not due to performance
    but due to e.g. some hardware being very timing-sensitive. I dont think
    we can make a blanket assumption that every code path is preemptable if
    all processing is synchronous and the exclusions are listened to.

    Ingo
    -
    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:04    [W:3.108 / U:0.124 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site