lkml.org 
[lkml]   [2008]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [patch] sched: prevent bound kthreads from changing cpus_allowed
From
Date
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().



\
 
 \ /
  Last update: 2008-06-10 08:49    [from the cache]
©2003-2011 Jasper Spaans