linux-kernel - Re: Overview of 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: <4C192CD5.8080602@kernel.org>
Date:	Wed, 16 Jun 2010 21:58:13 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Daniel Walker <dwalker@...eaurora.org>
CC:	mingo@...e.hu, awalls@...ix.net, linux-kernel@...r.kernel.org,
	jeff@...zik.org, akpm@...ux-foundation.org, rusty@...tcorp.com.au,
	cl@...ux-foundation.org, dhowells@...hat.com,
	arjan@...ux.intel.com, johannes@...solutions.net, oleg@...hat.com,
	axboe@...nel.dk
Subject: Re: Overview of concurrency managed workqueue

Hello,

On 06/16/2010 09:46 PM, Daniel Walker wrote:
>> If you actually _solve_ the problem like this, other users wouldn't
>> experience the problem at all once the update reaches them and you
>> won't have to worry about your workaround breaking with the next
>> kernel update or unexpected suspend/resume and we won't be having this
>> discussion about adjusting workqueue priorities from userland.
> 
> What you suggesting just means the user has to adjust an interrupt
> thread instead of a workqueue thread. That really doesn't change
> anything, since it's just another type of kernel thread.

It allows writing an interrupt handler which requires context and
PREEMPT_RT kernel will handle priority inheritance correctly with
them, so there's no priority inversion problem.

>> There are many wrong things about working around RT latency problems
>> by setting workqueue priorities from userland.  Please think about why
>> the driver would have a separate workqueue for itself in the first
>> place.  It was to work around the limitation of workqueue facility and
>> you're arguing that, because that work around allows yet another very
>> fragile workaround, the property which made the original work around
>> necessary in the first place needs to stay.  That sounds really
>> perverse to me.
> 
> I have no idea what your trying to say here.. I'm sure there is no one
> reason why people use workqueues in their drivers. In fact I'm sure
> there are many reasons to use workqueues or not to use them.

I mean that if workqueues don't have current limitations, there's no
reason for most drivers which aren't in the allocation path to use
separate workqueues.  They can simply use the default system one.

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/