Re: [RFC PATCH 0/6] Convert all tasklets to workqueues

["Kristian Høgsberg" <krh@redhat.com>]

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