From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756393AbbFPL4u (ORCPT ); Tue, 16 Jun 2015 07:56:50 -0400 Received: from e28smtp08.in.ibm.com ([122.248.162.8]:38868 "EHLO e28smtp08.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756115AbbFPL4i (ORCPT ); Tue, 16 Jun 2015 07:56:38 -0400 X-Helo: d28dlp02.in.ibm.com X-MailFrom: srikar@linux.vnet.ibm.com X-RcptTo: linux-kernel@vger.kernel.org From: Srikar Dronamraju To: Ingo Molnar , Peter Zijlstra Cc: linux-kernel@vger.kernel.org, srikar@linux.vnet.ibm.com, Rik van Riel , Mel Gorman Subject: [PATCH v2 3/4] sched:Fix task_numa_migrate to always update preferred node Date: Tue, 16 Jun 2015 17:26:01 +0530 Message-Id: <1434455762-30857-4-git-send-email-srikar@linux.vnet.ibm.com> X-Mailer: git-send-email 2.1.4 In-Reply-To: <1434455762-30857-1-git-send-email-srikar@linux.vnet.ibm.com> References: <1434455762-30857-1-git-send-email-srikar@linux.vnet.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15061611-0029-0000-0000-0000067496C9 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In task_numa_migrate(), env.dst_nid points to either a preferred node or a node that has free capacity and has more task weight than the current node. Currently in such a scenario, there are checks to see if tasks in the numa_group have previously run on the node that has free capacity before updating the preferred node. Commit (c1ceac62: "sched/numa: Reduce conflict between fbq_classify_rq() and migration") gives preferance to preferred node while load balancing. Hence if setting the preferred_node after evaluating is skipped, then the task might miss opportunity later at load balancing time to move to the preferred node. In such a scenario, it makes sense to unconditionally set env.dst_nid as the preferred node unless the said node is already the preferred node. While here, update env.dst_nid only when both task and groups benefit. This is as per the comment in the code. Signed-off-by: Srikar Dronamraju --- kernel/sched/fair.c | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 7b23efa..d1aa374 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -1503,7 +1503,7 @@ static int task_numa_migrate(struct task_struct *p) /* Only consider nodes where both task and groups benefit */ taskimp = task_weight(p, nid, dist) - taskweight; groupimp = group_weight(p, nid, dist) - groupweight; - if (taskimp < 0 && groupimp < 0) + if (taskimp < 0 || groupimp < 0) continue; env.dist = dist; @@ -1519,16 +1519,9 @@ static int task_numa_migrate(struct task_struct *p) * and is migrating into one of the workload's active nodes, remember * this node as the task's preferred numa node, so the workload can * settle down. - * A task that migrated to a second choice node will be better off - * trying for a better one later. Do not set the preferred node here. */ if (p->numa_group) { - if (env.best_cpu == -1) - nid = env.src_nid; - else - nid = env.dst_nid; - - if (node_isset(nid, p->numa_group->active_nodes)) + if (env.dst_nid != p->numa_preferred_nid) sched_setnuma(p, env.dst_nid); } -- 1.8.3.1