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

[Ingo Molnar]

* Kristian H?gsberg <krh@xxxxxxxxxx> wrote:

> 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.

regarding workqueues - would it be possible for you to test Steve's 
patch and get us performance numbers? Do you have any test with tons of 
tasklet activity that would definitely show the performance impact of 
workqueues? Workqueue priority can be set, and your handler should 
probably be SCHED_FIFO.

right now the tasklet-emulation workqueue is globally locked, etc., but 
if you use per-cpu workqueues then you'd probably get better scalability 
than tasklets. (yes, despite the extra scheduling (which only costs ~1 
microsecond) that the workqueue has to do.) Scheduling is pretty cheap, 
the basic overhead of servicing a single interrupt is often 10 times 
more expensive than a context-switch.

> 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?

i'd like to stress that your approach is completely fine and valid - and 
if what we propose impacts performance negatively without any acceptable 
(and robust) replacement solution offered by us then our patch wont be 
done - simple as that. Softirqs could be an additional (performance) 
advantage on SMP systems with multiple firewire interrupt sources, but 
it would have to be measured too.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/