lkml.org 
[lkml]   [2011]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2011-01-09 15:45    [W:0.055 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site