lkml.org 
[lkml]   [2012]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [patch,v2] bdi: add a user-tunable cpu_list for the bdi flusher threads
    Date
    Tejun Heo <tj@kernel.org> writes:

    > Hmmm... cpu binding usually is done by kthread_bind() or explicit
    > set_cpus_allowed_ptr() by the kthread itself. The node part of the
    > API was added later because there was no way to control where the
    > stack is allocated and we often ended up with kthreads which are bound
    > to a CPU with stack on a remote node.
    >
    > I don't know. @node usually controls memory allocation and it could
    > be surprising for it to control cpu binding, especially because most
    > kthreads which are bound to CPU[s] require explicit affinity
    > management as CPUs go up and down. I don't know. Maybe I'm just too
    > used to the existing interface.

    OK, I can understand this line of reasoning.

    > As for the original patch, I think it's a bit too much to expose to
    > userland. It's probably a good idea to bind the flusher to the local
    > node but do we really need to expose an interface to let userland
    > control the affinity directly? Do we actually have a use case at
    > hand?

    Yeah, folks pinning realtime processes to a particular cpu don't want
    the flusher threads interfering with their latency. I don't have any
    performance numbers on hand to convince you of the benefit, though.

    Cheers,
    Jeff


    \
     
     \ /
      Last update: 2012-12-06 20:01    [W:2.456 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site