linux-kernel - Re: [PATCH 34/35] async: use workqueue for worker pool

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: <4C2A2979.3000609@gmail.com>
Date:	Tue, 29 Jun 2010 19:12:25 +0200
From:	Tejun Heo <htejun@...il.com>
To:	Arjan van de Ven <arjan@...ux.intel.com>
CC:	Frederic Weisbecker <fweisbec@...il.com>,
	torvalds@...ux-foundation.org, mingo@...e.hu,
	linux-kernel@...r.kernel.org, jeff@...zik.org,
	akpm@...ux-foundation.org, rusty@...tcorp.com.au,
	cl@...ux-foundation.org, dhowells@...hat.com, oleg@...hat.com,
	axboe@...nel.dk, dwalker@...eaurora.org, stefanr@...6.in-berlin.de,
	florian@...kler.org, andi@...stfloor.org, mst@...hat.com,
	randy.dunlap@...cle.com, Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH 34/35] async: use workqueue for worker pool

On 06/29/2010 06:59 PM, Tejun Heo wrote:
> Hello, Arjan.
> 
> On 06/29/2010 06:40 PM, Arjan van de Ven wrote:
>> uh? clearly the assumption is that if I have a 16 CPU machine, and 12
>> items of work get scheduled,
>> that we get all 12 running in parallel. All the smarts of cmwq surely
>> only kick in once you've reached the
>> "one work item per cpu" threshold ???
> 
> Hmmm... workqueue workers are bound to certain cpu, so if you schedule
> a work on a specific CPU, it will run there.  Once a cpu gets
> saturated, the issuing thread will be moved elsewhere.  I don't think
> it matters to any of the current async users one way or the other,
> would it?

Thinking more about it.  It's now not difficult to add a gcwq for an
unbound pseudo CPU number and use it as host for workers which can run
on any CPU.  The automatic concurrency management doesn't make much
sense for those workers, so @max_active can be used as the explicit
concurrency throttle.  It's not even gonna take a lot of code but I'm
just not convinced that there's much benefit in doing that.  So, yeah,
if necessary, sure, but let's think whether it's gonna be actually
useful.

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/