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
| ||
|
Date: Fri, 18 Jun 2010 08:36:22 +0200 From: Florian Mickler <florian@...kler.org> To: Daniel Walker <dwalker@...eaurora.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, 17 Jun 2010 11:03:49 -0700 Daniel Walker <dwalker@...eaurora.org> wrote: > > 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) .. fair enough. let's stop the analogies here, i'm already sorry I started with it. :) > >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. No, the fact that multiple workers work on a workqueue decreases latency as well... (worst case latency would be the same, if there were a minimum limit for worker threads per queue. I'm not shure if this is implemented.. ) > > 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. you have a point here. I think the priority should go with the work-item though. Or do you think that is not a good solution? one priority-inheritance would be to increase the priority of all work-items queued before the "valuable" work item. another way is to just have enough worker-threads so that all work-items are executed as fast as possible (if necessary summoning new workers). a third is to have a separate worker-pool and workqueue for high-priority work. and i'm guessing there are more solutions... > > 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 .. No, no. Not setting priorities to drivers. What I wanted to get at, is that the one who shedules the work has to/can decide what priority that work should run as. I.e. the priority has to go with the work. Because you are upping the priority of a thread not for the thread's sake but for the work the thread is going to execute/executing? > > 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. I don't follow. What I thought about was, that the "workqueue" interface is defined in workqueue.h. There is no "increase_priority_of_workqueue()" or "increase_work_priority()" at the moment in the interface description. Fumbling at the threads is using _implementation knowledge_ that should be hidden by the interface. I'm not saying this is a binary true/false kind of "fact", just one view point. Also I agree that some ability to prioritize work items has to be enabled. And using the scheduler for that is the only sane alternative. But I think the workqueue-implementation should do it, so it has the freedom to dispatch threads at will. > > 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/
Powered by blists - more mailing lists