Messages in this thread | | | Date | Thu, 28 Jun 2007 11:23:40 +0200 | From | Ingo Molnar <> | Subject | Re: [RFC PATCH 0/6] Convert all tasklets to workqueues |
| |
* Jeff Garzik <jeff@garzik.org> wrote:
> Tasklets fill a niche not filled by either workqueues (slower, > requiring context switches, and possibly much latency is all wq's > processes are active) [...]
... workqueues are also possibly much more scalable (percpu workqueues are easy without changing anything in your code but the call where you create the workqueue).
the context-switch argument i'll believe if i see numbers. You'll probably need in excess of tens of thousands of irqs/sec to even be able to measure its overhead. (workqueues are driven by nice kernel threads so there's no TLB overhead, etc.)
the only remaining argument is latency: but workqueues are already pretty high-prio (with a default priority of nice -5) - and you can increase it even further. You can make it SCHED_FIFO prio 98 if latency is so important. Tasklets on the other hand are _unconditionally_ high-priority. So this argument is more of an arms-race argument: "i want _my_ processing to be done immediately!". The fact that workqueues can be preempted and that their priorities can be adjusted flexibly is an optional _bonus_, not a disadvantage. If low-prio workqueues hurts your workflow, make them high-prio.
> And moving code -back- into hardirq is just the wrong thing to do, > usually.
agreed - except if the in-tasklet processing is really thin and there's already a softirq layer in the workflow. (which the case was for the example that was cited.) In such a case moving either to the hardirq or to the softirq looks like the right thing - instead of the tasklet intermediary.
Ingo - 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/
| |