Messages in this thread | | | Date | Sun, 9 Jan 2011 09:41:54 -0500 | From | Tejun Heo <> | Subject | Re: Screwing with the concurrency limit |
| |
Hello,
On Sat, Jan 08, 2011 at 10:06:04AM -0800, Kent Overstreet wrote: > Well, that doesn't quite do it, I'd need workqueue_inc_max_active() > and workqueue_dec_max_active()... set_max_active() would be racy.
You'll of course need to grab an outer mutex around max_active updates.
> But also there's no point in adjusting max_active on every cpu's > workqueue, adjusting just the one on the local cpu would do exactly > what I want and be more efficient too... Can you see any issues in > doing it that way?
Can you please explain the use case a bit more? Is something per-cpu? ie. Are your write locks per-cpu? How frequent do you expect the write locking to be? I think adjusting max_active per-cpu should be doable but I'd rather stay away from that.
> What I was really hoping for was something like... maybe > move_work_to_workqueue() - if you could do that on the work item > you're executing, move it from the workqueue that has max_active = 1 > to a different one - it's stateless from the caller's perspective.
I don't think that's gonna be a good idea. It's too specialized soultion which is likely to bite our asses down the road.
> But I suspect that'd be more complicated than your way of doing it, > and inc()/dec() is probably just as good...
So, I think it would be better to make max_active manipulation work somehow but again I want to stay way from being too specialized.
Thank you.
-- tejun
| |