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

Hello,

On 12/19/2009 12:01 AM, 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...

A resource not being scarce is very different from a resource being
limitless and doesn't mean we can use them without thinking about it.
If we haven't been trying to limit the number of threads used by
various subsystems, we could easily be looking at far larger number of
threads than we're using now and things would be breaking at the far
ends of the spectrum (very small or extremely large systems).

What cmwq does is managing this not-so-scarce resource automatically
at a single place and because the resource is not so scarce, it can be
made very mechanical and reliable.  No need to worry about managing
concurrencies or limit the number of threads from other places.  Sure,
it involves some amount of complex code in implementing workqueue
itself but we'll be removing a lot of complexities and codes from more
peripheral places and that is the right direction to go.  We can
easily get the core code right and after being properly debugged, cmwq
won't be fragile.  As an async mechanism, its operation is highly
deterministic and mechanical.

Thanks.

-- 
tejun
--
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/