Messages in this thread | | | Date | Tue, 08 Dec 2009 20:24:58 +0900 | From | Tejun Heo <> | Subject | Re: [PATCH 4/7] sched: implement force_cpus_allowed() |
| |
Hello,
On 12/08/2009 07:34 PM, Peter Zijlstra wrote: > On Tue, 2009-12-08 at 18:12 +0900, Tejun Heo wrote: >>> 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? >> >> Yes, that's all I need.
Let me augment the above sentence. Yes, that's all I need *during CPU_DOWN*. During CPU_UP, I need to migrate back left running workers which survived from the last CPU_DOWN. In the original patch, the down path is worker_maybe_bind_and_lock() and the latter path is trustee_unset_rogue().
> Then you don't need most of that patch, you don't need to touch the > migration stuff since a new kthread isn't running. > > All you need to do is make a kthread_bind/set_cpus_allowed variant that > checks against cpu_online_mask instead of cpu_active_mask.
kthread_bind() doesn't check against cpu_online_mask. Isn't set_cpus_allowed() variant which checks against cpu_online_mask is what's implemented by the patch (+ PF_THREAD_BOUND bypass)?
> It might even make sense to have kthread_bind() always check with > cpu_online_mask as the kernel really ought to know what its doing > anyway.
Oh... yeah, it was a bit strange that the function doesn't check against cpu onliness but if that is removed what would be the point of kthread_bind() when set_cpus_allowed() provides pretty much the same capability?
> You also don't need to play trickery with PF_THREAD_BOUND, since a new > kthread will not have that set.
Yeap, but when the cpu comes back online, those kthreads need to be rebound to the cpu.
> In fact, your patch is against a tree that still has cpu_online_mask in > all those places, so you wouldn't have needed any of that, confused.. ?!
To migrate back the workers from CPU_ONLINE callback.
Thanks.
-- tejun
| |