* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Whether we actually then want to do 6 is another matter. I think we'd
> need some measuring and discussion about that.
basically tasklets have a number of limitations:
- tasklets have certain latency limitations over real tasks. (for
example they are not guaranteed to be re-executed when they are
triggered while they are running, so artificial latencies can be
introduced into the kernel workflow)
- tasklets have certain execution limitations. (only atomic functions
can be executed in them)
- tasklets have certain fairness limitations. (they are executed in
softirq context and thus preempt everything, even if there is some
potentially more important, high-priority task waiting to be
executed.)
- the 'priority levels' approach of softirqs is not really
self-documenting - unlike real locks. As a result we've got some
vague coupling between network softirq processing and timer softirq
processing, which spilled over into tasklets as well. The 'hi' and
'low' concept of tasklets isnt really used either. We should reduce
the amount of such opaque 'coupling' between workflows - it should be
spelled out explicitly via some synchronization construct.
- tasklets are duplicated infrastructure (over existing workqueues)
that, if it's possible to do it compatibly, would be a good idea to
eliminate.
when it comes to 'deferred processing', we've basically got two 'prime'
choices for deferred processing:
- if it's high-performance then it goes into a softirq.
- if performance is not important, or robustness and flexibility is
more important than performance, then workqueues are used.
basically tasklets do _neither_ really well. They are too 'global' to
scale really well on SMP (even the RCU tasklet wasnt a real tasklet: it
was a _per CPU tasklet_, which almost by definition is equivalent to a
softirq, some some extra glue overhead ...), and tasklets are also too
much tied to softirqs to be used as a generic processing context.
that's why i'd like them to be gently but firmly phased out =B-)
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/
