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]

Message-ID: <20070628092340.GB23566@elte.hu>
Date:	Thu, 28 Jun 2007 11:23:40 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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

* Jeff Garzik <jeff@...zik.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/