lkml.org 
[lkml]   [2007]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC PATCH 0/6] Convert all tasklets to workqueues
    From
    Date
    On Fri, 2007-06-22 at 23:59 +0200, Ingo Molnar wrote:
    > so how about the following, different approach: anyone who has a tasklet
    > in any performance-sensitive codepath, please yell now. We'll also do a
    > proactive search for such places. We can convert those places to
    > softirqs, or move them back into hardirq context. Once this is done -
    > and i doubt it will go beyond 1-2 places - we can just mass-convert the
    > other 110 places to the lame but compatible solution of doing them in a
    > global thread context.

    OK, here's a yell. I'm using tasklets in the new firewire stack for all
    interrupt handling. All my interrupt handler does is read out the event
    mask and schedule the appropriate tasklets. Most of these tasklets
    typically just end up scheduling work or completing a completion, so
    moving it to a workqueue is pretty pointless. In particular, the
    isochronous DMA events must be handled with as little latency as
    possible, so a workqueue in that code path would be pretty bad.

    I'm not strongly attached to tasklets, and it sounds like I got it wrong
    and used the wrong delayed execution mechanism. But that's just another
    data point that suggests that there are too many of these. I guess I
    need to sit down and look into porting that to softirqs?

    However, I don't really understand how you can discuss a wholesale
    replacing of tasklets with workqueues, given the very different
    execution sematics of the two mechanisms. I would think that others
    have used tasklets for similar purposes as I have and moving that to
    workqueues just has to break a bunch of stuff. I don't know the various
    places tasklets are used as well as other people in this thread, but I
    think deprecating them and moving code to either softirqs or workqueues
    on a case by case basis is a better approach. That way we also avoid
    the gross wrappers.

    Kristian


    -
    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-25 20:53    [W:3.048 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site