lkml.org 
[lkml]   [2005]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    Date
    From
    SubjectRe: RT patch acceptance
    On Fri, May 27, 2005 at 03:56:44PM +0200, Takashi Iwai wrote:
    > At 27 May 2005 15:31:22 +0200,
    > Andi Kleen wrote:
    > >
    > > On Fri, May 27, 2005 at 03:13:17PM +0200, Ingo Molnar wrote:
    > > >
    > > > > > but it's certainly not for free. Just like there's no zero-cost
    > > > > > virtualization, or there's no zero-cost nanokernel approach either,
    > > > > > there's no zero-cost single-kernel-image deterministic system either.
    > > > > >
    > > > > > and the argument about binary kernels - that's a choice up to vendors
    > > > >
    > > > > It is not only binary distribution kernels. I always use my own self
    > > > > compiled kernels, but I certainly would not want a special kernel just
    > > > > to do something normal that requires good latency (like sound use).
    > > >
    > > > for good sound you'll at least need PREEMPT_VOLUNTARY. You'll need
    > > > CONFIG_PREEMPT for certain workloads or pro-audio use.
    > >
    > > AFAIK the kernel has quite regressed recently, but that was not true
    > > (for reasonable sound) at least for some earlier 2.6 kernels and
    > > some of the low latency patchkit 2.4 kernels.
    > >
    > > So it is certainly possible to do it without preemption.
    >
    > Yes, as Ingo stated many times, addition cond_resched() to
    > might_sleep() does achieve the "usable" latencies -- and obviously
    > that's hacky.

    But it's the only way to get practial(1)low latency benefit to everybody -
    not just a few selected few who know how to set the right
    kernel options or do other incarnations and willfully give up performance
    and stability.

    It is basically similar to why we often avoid kernel tunables - the
    kernel must work well out of the box.

    (1) = not necessarily provable, but good enough at least for jack et.al.

    >
    > So, the only question is whether changing (inserting) cond_resched()
    > to all points would be acceptable even if it results in a big amount
    > of changes...

    We've been doing that for years, haven't we. The main criterium
    should be not to change code, but to not affect performance considerably.

    -Andi
    -
    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-05-30 11:59    [W:3.886 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site