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: <4C19DCC2.9070708@kernel.org>
Date:	Thu, 17 Jun 2010 10:28:50 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Florian Mickler <florian@...kler.org>
CC:	Daniel Walker <dwalker@...eaurora.org>, 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/17/2010 07:29 AM, Florian Mickler wrote:
> Once you have the priority in the driver you could pass it to the
> workqueue subsystem (i.e. set the priority of the work) and the worker
> could then assume the priority of its work.
> 
> The tricky part is probably to pass the priority from the userspace
> thread to the kernel?

There are several things to consider.  First of all, workqueue
latencies would be much lower with cmwq because works don't need to
wait for other works on the same wq to complete.  So, in general, the
latencies will be more predictable and lower.

Secondly, work items don't tend to burn a lot of cpu cycles.  Combined
with the first point, there might not be much benefit to doing all the
extra work for prioritizing work items (as what matters is getting
them to start running quickly and cmwq helps a lot in that direction).

Thirdly, on !RT kernel, RT doesn't have any guarantee anyway.  It's
just higher priority.  For real RT, if work items should be capable of
being part of critical path, implementing proper priority inheritance
is necessary so that flush_work() and possibly flush_workqueue() can
bump the waited works on behalf of RT thread waiting on them.  Whether
that would be a worth investment or just not using work items in
critical path is better, I don't know.

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/