lkml.org 
[lkml]   [2012]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 07/39] autonuma: introduce kthread_bind_node()
    From
    Date
    On Tue, 2012-03-27 at 18:04 +0200, Andrea Arcangeli wrote:
    > On Tue, Mar 27, 2012 at 05:45:35PM +0200, Peter Zijlstra wrote:
    > > On Tue, 2012-03-27 at 17:22 +0200, Andrea Arcangeli wrote:
    > > > I don't see what's wrong with more than 1 CPU in the hard bind
    > > > cpumask.
    > >
    > > Because its currently broken, but we're trying to restore its pure
    > > semantic so that we can use it in more places again, like
    > > debug_smp_processor_id(). Testing a single process flag is _much_
    > > cheaper than testing ->cpus_allowed.
    > >
    > > Adding more broken isn't an option.
    >
    > I would suggest you to use a new bitflag for that _future_
    > optimization that you plan to do without altering the way the current
    > bitflag works.
    >
    > I doubt knuma_migrated will ever be the only kernel thread that wants
    > to run with a NUMA NODE-wide CPU binding (instead of single-CPU
    > binding).
    >
    > Being able to keep using this bitflag for NUMA-wide bindings too in
    > the future as well (after you do the optimization you planned), is
    > going to reduce the chances of the root user shooting himself in the
    > foot for both the kernel thread node-BIND and the single-cpu-BIND.

    But then the current flag is a mis-nomer. Also, there's no correctness
    issue with the per-node threads, its perfectly fine if they run some
    place else so I don't think we should restrict userspace to force them
    away from their preferred node.

    So even if you were to introduce a new flag, I'd still object.

    The only reason to ever refuse userspace moving a task around is if it
    will break stuff. Worst that can happen with a node affine thread is
    that it'll incur remote memory penalties, that's not fatal.


    \
     
     \ /
      Last update: 2012-03-27 18:23    [W:3.039 / U:0.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site