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: <1276797829.29614.42.camel@c-dwalke-linux.qualcomm.com>
Date:	Thu, 17 Jun 2010 11:03:49 -0700
From:	Daniel Walker <dwalker@...eaurora.org>
To:	Florian Mickler <florian@...kler.org>
Cc:	Tejun Heo <tj@...nel.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

On Thu, 2010-06-17 at 07:29 +0200, Florian Mickler wrote:
>  
> 
> For what its worth, IMO the right thing to do would probably be to
> propagate the priority through the subsystem into the driver. 
> 
> Not fumbling with thread priorities. As Tejun said, these are not
> really userspace ABI ... (It's like hitting at the side of a vending
> machine if the coin is stuck... may work, but definitely not
> supported by the manufacturer) 

I don't agree with your analogy here .. It's more like you have two
items in the vending machine item A and item B. Tejun is saying he likes
item A, his friends like item A so that must mean item B is not
interesting so he removes it (without knowing how many people want it). 
So what happens? People use another vending machine. (Linux is the
vending machine) ..

>>From my perspective this is like using Linux only for throughput which
is what Tejun is maximizing. In addition Tejun is blowing up the
alternative which is to prioritize the work items and sticking you with
strictly a throughput based system.

Do you thing maybe it's possible that the work items aren't all created
equal? Maybe one item _is_ more important than another one. Maybe on a
given system Tejun's workqueues runs a 1000 useless pointless work items
before he gets to the valuable one .. Yet the user is powerless to
dictate what is or is not important.

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

Threads are designed to have priorities tho, and threads are pervasive
throughout Linux .. It seems like setting a priorities to drivers would
be like re-inventing the wheel ..

If you were to say make the driver use kthreads instead of workqueues,
then you could set the priority of the kthreads .. However, you said
this isn't part of the ABI and so your back to your original argument
which is that you shouldn't be setting priorities in the first place.

Daniel

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