lkml.org 
[lkml]   [2004]   [Jul]   [21]   [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:

    > > > You're still running do_softirq() with preemption disabled, which is
    > > > almost as bad as doing it under a lock.
    > >
    > > well softirqs are designed like that.
    >
    > And those who wish to continue using them like that can. However, in
    > my patch they never run with preemption disabled, which can result in
    > substantial latency improvement (as long as nothing else is causing
    > similar delays). I see nothing in the design that *requires* them to
    > continue running with preemption disabled.

    did you get my other mail in which i explained how e.g. the networking
    code _relies_ on the softirq semantics?

    of course you can improve latencies by making something preemptible that
    wasnt preemptible before, but if you do that you should be absolutely
    sure that it can be done without breaking that code. And in this case it
    cannot be done. The comments in your patch also suggest that you were
    unsure about this issue:

    +/* As far as I can tell, local_bh_disable() didn't stop ksoftirqd
    + from running before. Since all softirqs now run from one of
    + the ksoftirqds, this shouldn't be necessary. */
    +
    +static inline void local_bh_disable(void)
    +{
    +}

    local_bh_disable() of course stops ksoftirqd from running on that CPU.

    > Do you also add preemption checks in all of the various loops that can
    > be run from within a single softirq instance?

    no, that's the next step, if those loops turn out to be problematic.
    E.g. network device backlogs default to a value of 100 or so which
    shouldnt generate too bad latencies. If it does it's easy to break out
    of those loops, they are already breakout-aware.

    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.411 / U:0.296 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site