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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 22 Jun 2007 22:40:58 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Christoph Hellwig <hch@...radead.org>,
	john stultz <johnstul@...ibm.com>,
	Oleg Nesterov <oleg@...sign.ru>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Dipankar Sarma <dipankar@...ibm.com>,
	"David S. Miller" <davem@...emloft.net>, matthew.wilcox@...com,
	kuznet@....inr.ac.ru
Subject: Re: [RFC PATCH 0/6] Convert all tasklets to workqueues


* Linus Torvalds <torvalds@...ux-foundation.org> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/