Messages in this thread | | | Subject | Re: [PATCH 4/7] sched: implement force_cpus_allowed() | From | Peter Zijlstra <> | Date | Tue, 08 Dec 2009 10:02:43 +0100 |
| |
On Tue, 2009-12-08 at 17:41 +0900, Tejun Heo wrote: > Hello, > > On 12/07/2009 08:07 PM, Tejun Heo wrote: > > On 12/07/2009 07:54 PM, Peter Zijlstra wrote: > >> So we seem to do cleanup_workqueue_thread() from CPU_POST_DEAD, but at > >> that time any thread that might still be around will most certainly not > >> be running on the offlined cpu anymore. > >> > >> If you really want to ensure you remain on the cpu, you have to complete > >> from CPU_DOWN_PREPARE. > >> > >> We're not running things from offline CPUs. > > > > Oh, no, we're not doing that. We can't do that. What we're doing is > > to continue to process works which were queued on the now offline cpu > > unless it has been flushed/cancled from one of the cpu down > > notifications and the reason why we need to be able to fork after > > active is clear is to guarantee those flush/cancels don't deadlock. > > Does my explanation justify the patch?
So its only needed in order to flush a workqueue from CPU_DOWN_PREPARE? And all you need it to place a new kthread on a !active cpu?
Or is this in order to allow migrate_live_tasks() to move the worker threads away from the dead cpu?
I'm really not thrilled by the whole fork-fest workqueue design.
| |