Messages in this thread | | | Date | Thu, 3 Apr 2014 17:43:07 +0200 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 2/4] workqueues: Account unbound workqueue in a seperate list |
| |
On Thu, Apr 03, 2014 at 11:01:28AM -0400, Tejun Heo wrote: > Hello, > > On Thu, Apr 03, 2014 at 04:48:28PM +0200, Frederic Weisbecker wrote: > > > Wouldn't the right thing to do would be factoring out > > > apply_workqueue_attrs_locked()? It's cleaner to block out addition of > > > new workqueues while the masks are being updated anyway. > > > > I'm not quite sure I get what you suggest. Do you mean have > > apply_workqueue_attrs_locked() calling apply_workqueue_attrs() under > > the lock on this patch? > > Not sure it still matters but I was suggesting that creating > apply_workqueue_attrs_locked() which requires the caller to handle > locking and making apply_workqueue_attrs() a wrapper which grabs and > releases lock around it, and using the former in locked iteration > would work. lol has this explanation made it any clearer or is it > even worse now? :)
I see, it gets a little better now :)
Maybe it still matters because I still need to iterate over unbound workqueues to apply an update on "cpu_unbound_wqs_mask". And the list must remain stable while I call apply_workqueue_attrs() on workqueues.
Anyway, we'll see how it looks like :)
| |