Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754253AbbGIWNI (ORCPT ); Thu, 9 Jul 2015 18:13:08 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:53018 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752792AbbGIWNA (ORCPT ); Thu, 9 Jul 2015 18:13:00 -0400 Date: Thu, 9 Jul 2015 15:12:59 -0700 From: Andrew Morton To: Nathan Zimmer Cc: Nishanth Aravamudan , Tejun Heo , Lai Jiangshan , Mel Gorman , linux-kernel@vger.kernel.org, Eric Dumazet Subject: Re: [RFC] kthread_create_on_node is failing to honor the node choice Message-Id: <20150709151259.2ce6a8882d0c98ae77528667@linux-foundation.org> In-Reply-To: <1435268653-167841-1-git-send-email-nzimmer@sgi.com> References: <20150625204855.GC26927@suse.de> <1435268653-167841-1-git-send-email-nzimmer@sgi.com> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2354 Lines: 56 On Thu, 25 Jun 2015 16:44:13 -0500 Nathan Zimmer wrote: > In kthread_create_on_node we set_cpus_allowed to cpu_all_mask > regardless of what the node is requested. > This seems incorrect. The `node' arg to kthread_create_on_node() refers to which node the task_struct and thread_info are allocated from. It doesn't refer to the CPUs upon which the thread is executed. See kthread_create_info.node and that gruesome task_struct.pref_node_fork thing. The kthread_create_on_node() kerneldoc explains this, in a confused way. It needs a s/-1/NUMA_NO_NODE/. I'm a bit surprised that kthread_create_on_node() futzes with the new thread's policy and cpumask after it has been created. Wouldn't it be simpler/faster to have the thread itself set these things while it's starting up? As to whether kthread_create_on_node() should bind the thread to that node's CPUs: unclear. drivers/thermal/intel_powerclamp.c:start_power_clamp() understands how kthread_create_on_node() works. I guess the code is OK as-is, but the documentation could be improved. Perfunctory effort: --- a/kernel/kthread.c~a +++ a/kernel/kthread.c @@ -246,7 +246,7 @@ static void create_kthread(struct kthrea * kthread_create_on_node - create a kthread. * @threadfn: the function to run until signal_pending(current). * @data: data ptr for @threadfn. - * @node: memory node number. + * @node: task and thread structures for the thread are allocated on this node * @namefmt: printf-style name for the thread. * * Description: This helper function creates and names a kernel @@ -254,7 +254,7 @@ static void create_kthread(struct kthrea * it. See also kthread_run(). * * If thread is going to be bound on a particular cpu, give its node - * in @node, to get NUMA affinity for kthread stack, or else give -1. + * in @node, to get NUMA affinity for kthread stack, or else give NUMA_NO_NODE. * When woken, the thread will run @threadfn() with @data as its * argument. @threadfn() can either call do_exit() directly if it is a * standalone thread for which no one will call kthread_stop(), or _ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/