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: <1261504042.4937.59.camel@laptop>
Date:	Tue, 22 Dec 2009 18:47:22 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Tejun Heo <tj@...nel.org>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Jens Axboe <jens.axboe@...cle.com>,
	Andi Kleen <andi@...stfloor.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 Tue, 2009-12-22 at 09:20 -0800, Linus Torvalds wrote:
> 
> So stop arguing about irrelevancies. Nobody uses workqueues for RT or for 
> CPU-intensive crap. It's not what they were designed for, or used for.

RT crap maybe, but cpu intensive bits are used for sure, see the
crypto/crypto_wq.c drivers/md/dm*.c.

I've seen those consume significant amounts of cpu, now I'm not going to
argue that workqueues are not the best way to consume lots of cpu, but
the fact is they _are_ used for that.

And since tejun's thing doesn't have wakeup parallelism covered these
uses can turn into significant loads.

> If you _want_ to use them for that, that is _your_ problem. Not Tejuns.

I don't want to use workqueues at all.

> People use workqueues for other things _today_, and they have annoying 
> problems as they stand. It would be nice to get rid of the deadlock 
> issue, for example - right now the tty driver literally does crazy things, 
> and drops locks that it shouldn't drop due to the fact that it needs to 
> wait for queued work - even if the queued work it is actually waiting for 
> isn't the one that takes the lock!

Which in turn would imply we cannot carry fwd the current lockdep
annotations, right?

Which means we'll be stuck in a situation where A flushes B and B
flushes A will go undetected until we actually hit it.

Where exactly does the tty thing live in the code?

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