Hello, On Tue, Dec 04, 2012 at 05:26:26PM -0500, Jeff Moyer wrote: > I think it's a bit more involved than that. If you look at > kthread_create_on_node, the node portion only applies to where the > memory comes from, it says nothing of scheduling. To whit: > > /* > * root may have changed our (kthreadd's) priority or CPU mask. > * The kernel thread should not inherit these properties. > */ > sched_setscheduler_nocheck(create.result, SCHED_NORMAL, ¶m); > set_cpus_allowed_ptr(create.result, cpu_all_mask); > > So, if I were to make the change you suggested, I would be modifying the > existing behaviour. The way things stand, I think > kthread_create_on_node violates the principal of least surprise. ;-) I > would prefer a variant that affected scheduling behaviour as well as > memory placement. Tejun, Peter, Ingo, what are your opinions? 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. 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? Thanks. -- tejun -- 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>