linux-kernel - Re: [RFC PATCHSET] workqueue: implement concurrency managed workqueue

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: <20091001084733.GO14918@kernel.dk>
Date:	Thu, 1 Oct 2009 10:47:33 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Tejun Heo <tj@...nel.org>, Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Avi Kivity <avi@...hat.com>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	jeff@...zik.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, rusty@...tcorp.com.au,
	cl@...ux-foundation.org, dhowells@...hat.com, arjan@...ux.intel.com
Subject: Re: [RFC PATCHSET] workqueue: implement concurrency managed
	workqueue

On Thu, Oct 01 2009, Ingo Molnar wrote:
> My main worry is that in practice workqueues arent all that performance 
> critical - so we are shooting to optimize something that doesnt 
> necessarily use all the potential goodness inherent in this approach.

Well, the main problem with the current code is that per-cpu workqueues
are way abused. I don't look at this patchset from a performance point
of view, but rather a way to limit this huge number of idle and
pointless threads. Another issue are specific workqueues to deal with
slowly executing work, or dependency issues. The end result is just
hundreds of pointless kernel threads. I have two 64-thread boxes here, I
dare not think what the 128 or 256 thread (and even bigger) boxes look
like when booted. The latter would be safely into the thousands of
useless threads.

If we get this right, we'll have a leaner kernel and far fewer threads.
On the source side, we'll potentially get rid of specialized workqueue
akin implementations.

It's a win-win as far as I'm concerned.

-- 
Jens Axboe

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