lkml.org 
[lkml]   [2008]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] sched: prevent bound kthreads from changing cpus_allowed
    On Thu, 5 Jun 2008, Paul Jackson wrote:

    > A couple of questions on this:
    >
    > 1) Sometimes threads are bound to a set of CPUs, such as the CPUs
    > on a particular node:
    >
    > drivers/pci/pci-driver.c: set_cpus_allowed_ptr(current, nodecpumask);
    > net/sunrpc/svc.c: set_cpus_allowed_ptr(current, nodecpumask);
    >
    > Such cases can't invoke kthread_bind(), as that only binds to a single CPU.
    > I only see one place in your patch that sets PF_THREAD_BOUND; would it make
    > sense for such multi-CPU binds as above to be PF_THREAD_BOUND as well?
    >

    Not in the drivers/pci/pci-driver.c case because the setting of
    cpus_allowed to nodecpumask is only temporary (as is the disabling of the
    mempolicy). It's just done for the probe callback and then reset to the
    old cpumask. So any migration here would be lost.

    I can't speculate about the net/sunrpc/svc.c case because I don't know if
    user migration is harmful or discouraged. The behavior with my patch is
    the same for any calls to set_cpus_allowed_ptr() for tasks that haven't
    called kthread_bind(), so I'll leave that decision up to those who know
    best for this networking code.

    > 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.

    David


    \
     
     \ /
      Last update: 2008-06-05 23:15    [W:6.437 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site