Messages in this thread | | | Date | Tue, 4 Sep 2012 18:12:35 -0700 | From | Tejun Heo <> | Subject | Re: [PATCH 04/10 V4] workqueue: add manage_workers_slowpath() |
| |
Hello, Lai.
On Sun, Sep 02, 2012 at 12:28:22AM +0800, Lai Jiangshan wrote: > If hotplug code grabbed the manager_mutex and worker_thread try to create > a worker, the manage_worker() will return false and worker_thread go to > process work items. Now, on the CPU, all workers are processing work items, > no idle_worker left/ready for managing. It breaks the concept of workqueue > and it is bug. > > So when manage_worker() failed to grab the manager_mutex, it should > try to enter normal process contex and then compete on the manager_mutex > instead of return false. > > To safely do this, we add manage_workers_slowpath() and the worker > go to process work items mode to do the managing jobs. thus > managing jobs are processed via work item and can free to compete > on manager_mutex.
Ummm.... this seems overly complicated. How about scheduling rebind work to a worker and forcing it to break out of the work processing loop? I think it can be done fairly easily using POOL_MANAGE_WORKERS - set it from the rebind function, break out of work processing loop if it's set, replace need_to_manage_workers() with POOL_MANAGE_WORKERS test (the function really isn't necessary) and always jump back to recheck afterwards. It might need a bit more mangling here and there but that should be the essence of it. I'll give a stab at it later today.
Thanks.
-- tejun
| |