From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756923AbbFPRTB (ORCPT ); Tue, 16 Jun 2015 13:19:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36555 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752711AbbFPRSw (ORCPT ); Tue, 16 Jun 2015 13:18:52 -0400 Message-ID: <55805A7B.3070600@redhat.com> Date: Tue, 16 Jun 2015 13:18:51 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Srikar Dronamraju , Ingo Molnar , Peter Zijlstra CC: linux-kernel@vger.kernel.org, Mel Gorman Subject: Re: [PATCH v2 3/4] sched:Fix task_numa_migrate to always update preferred node References: <1434455762-30857-1-git-send-email-srikar@linux.vnet.ibm.com> <1434455762-30857-4-git-send-email-srikar@linux.vnet.ibm.com> In-Reply-To: <1434455762-30857-4-git-send-email-srikar@linux.vnet.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/16/2015 07:56 AM, Srikar Dronamraju wrote: > @@ -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); > } Looking at the original code again, it looks like my code has a potential bug (or at least downside), too. We set p->numa_group->active_nodes depending on which nodes a group triggers many NUMA faults happen from (the CPUs the tasks in the group were running on when they had NUMA faults). This means if a workload is not yet converged, the active_nodes mask may be much larger than desired, and we can end up setting p->numa_preferred_nid to a node that is currently in the active_nodes mask, but really shouldn't be... I have no ideas on how to improve that situation, though :)