lkml.org 
[lkml]   [2007]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 0/6] Convert all tasklets to workqueues
    Hello!

    > > The difference between softirqs and hardirqs lays not in their
    > > "heavyness". It is in reentrancy protection, which has to be done with
    > > local_irq_disable(), unless networking is not isolated from hardirqs.
    >
    > i know that pretty well ;)

    You forgot about this again in the next sentence. :-)


    > as i said above (see the underlined sentence), hardirq contexts already
    > run just fine with hardirqs enabled.

    RENTRANCY PROTECTION! If does not matter _how_ they run, it matters what
    context they preempt and what that context has to make to prevent that
    preemption. If you still do not get the point, make
    sed -e 's/local_bh_/local_irq_/'
    over net/* and kill softirqs. Everything will work just fine.
    Moreover, if you deal only with a single TCP connection
    (and sysctl tcp_low_latency is not set), even hardirq latency will not suck,
    all real work is done at process context.


    > also, network softirq locking dependencies arent all that magic or
    > complex either: they do not operate on sockets that are already locked
    > by a user context, they are per CPU and they are not preempted by
    > 'themselves', nor are they preempted by certain other softirqs (such as
    > they are not preempted by the timer softirq). Am i missing some point of
    > yours?

    I would not say I understood what you wanted to say. :-)

    Does my statement about sed match your view? :-)


    What I know is that there is no hairy locking dependencies at all
    and there is no magic there. Especially, on level of sockets.
    The things, which are troublesome are various shared trees/hash tables
    (e.g. socket hash tables), which are modified both by incoming network
    packets and process contexts.

    I have some obscure suspicion that naive dream of "realtime" folks is
    to move all those "bad" things to some kernel threads and to talk
    to those threads passing some messages. I hope this suspicion is wrong,
    otherwise I would say: go to Mach, pals. :-(

    Alexey
    -
    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: 2007-06-29 15:29    [W:4.056 / U:0.460 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site