[lkml]   [2004]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch
    On Wed, Jul 21, 2004 at 11:18:26PM +0200, Ingo Molnar wrote:
    > trying to make softirqs preemptible surely wont fly for 2.6 and it will
    > also overly complicate the softirq model. What's so terminally wrong
    > about adding preemption checks to the softirq paths? It should solve the
    > preemption problem for good. The unbound softirq paths are well-known
    > (mostly in the networking code) and already have preemption-alike
    > checks.

    These folks are tring to make the entire kernel fully preemptable,
    possibly, to handle arbitrary preemption at any point during the
    execution. It's a noble task to make the kernel preemptable in that
    way, but what I've seen is that the use of non-preemptive critical
    sections commits all locks below it in the call/lock graph to also
    be non-preemptive critical sections and therefore forcing the use
    of traditional lock-break and other techniques to lower latency.

    Adding preemption points helps with the problems, but isn't something
    that can be guaranteed to have a certain latency within N numbers of
    context switches and some rescheduling computations, etc...

    IMO, this is something that the Linux community should think about
    being friendly to or have some kind of consideration for the possibility
    of this.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:04    [W:0.048 / U:33.976 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site