* Kristian H?gsberg <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
