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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href