Re: Screwing with the concurrency limit

[Tejun Heo]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/