Re: [PATCH 07/39] autonuma: introduce kthread_bind_node()
From: Peter Zijlstra
Date: Tue Mar 27 2012 - 12:20:25 EST
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
> 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/