linux-kernel - Re: workqueue thing

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: <20091221110929.GF25372@basil.fritz.box>
Date:	Mon, 21 Dec 2009 12:09:30 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	Arjan van de Ven <arjan@...ux.intel.com>,
	Andi Kleen <andi@...stfloor.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Tejun Heo <tj@...nel.org>, torvalds@...ux-foundation.org,
	awalls@...ix.net, linux-kernel@...r.kernel.org, jeff@...zik.org,
	mingo@...e.hu, akpm@...ux-foundation.org, rusty@...tcorp.com.au,
	cl@...ux-foundation.org, dhowells@...hat.com, avi@...hat.com,
	johannes@...solutions.net
Subject: Re: workqueue thing

On Mon, Dec 21, 2009 at 10:17:54AM +0100, Jens Axboe wrote:
> On Fri, Dec 18 2009, Arjan van de Ven wrote:
> > in addition, threads are cheap. Linux has no technical problem with
> > running 100's of kernel threads (if not 1000s); they cost basically a
> > task struct and a stack (2 pages) each and that's about it.  making an
> > elaborate-and-thus-fragile design to save a few kernel threads is
> > likely a bad design direction...
> 
> One would hope not, since that is by no means outside of what you see on
> boxes today... Thousands. The fact that they are cheap, is not an
> argument against doing it right. Conceptually, I think the concurrency
> managed work queue pool is a much cleaner (and efficient) design.

Agreed. Even if possible thousands of threads waste precious cache.
And they look ugly in ps.

Also the nice thing about dynamically sizing the thread pool
is that if something bad (error condition that takes long) happens 
in one work queue for a specific subsystem there's still a chance 
to make process with other operations in the same subsystem.

-Andi
-- 
ak@...ux.intel.com -- Speaking for myself only.
--
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/