Messages in this thread |  | | | Subject | Re: [patch] sched: prevent bound kthreads from changing cpus_allowed | | From | Peter Zijlstra <> | | Date | Tue, 10 Jun 2008 08:44:00 +0200 |
| |
On Mon, 2008-06-09 at 13:59 -0700, Max Krasnyanskiy wrote: > David Rientjes wrote: > >> 2) Sometimes calls to kthread_bind are binding to any online cpu, such as in: > >> > >> drivers/infiniband/hw/ehca/ehca_irq.c: kthread_bind(cct->task, any_online_cpu(cpu_online_map)); > >> > >> In such cases, the PF_THREAD_BOUND seems inappropriate. The caller of > >> kthread_bind() really doesn't seem to care where that thread is bound; > >> they just want it on a CPU that is still online. > >> > > > > This particular case is simply moving the thread to any online cpu so that > > it survives long enough for the subsequent kthread_stop() in > > destroy_comp_task(). So I don't see a problem with this instance. > > > > A caller to kthread_bind() can always remove PF_THREAD_BOUND itself upon > > return, but I haven't found any cases in the tree where that is currently > > necessary. And doing that would defeat the semantics of kthread_bind() > > where these threads are supposed to be bound to a specific cpu and not > > allowed to run on others. > > Actually I have another use case here. Above example in particular may be ok > but it does demonstrate the issue nicely. Which is that in some cases kthreads > are bound to a CPU but do not have a strict "must run here" requirement and > could be moved if needed. > For example I need an ability to move workqueue threads. Workqueue threads do > kthread_bind().
Per cpu workqueues should stay on their cpu.
What you're really looking for is a more fine grained alternative to flush_workqueue().
|  |