From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756751Ab3JIR0x (ORCPT ); Wed, 9 Oct 2013 13:26:53 -0400 Received: from terminus.zytor.com ([198.137.202.10]:56007 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754774Ab3JIR0t (ORCPT ); Wed, 9 Oct 2013 13:26:49 -0400 Date: Wed, 9 Oct 2013 10:26:12 -0700 From: tip-bot for Peter Zijlstra Message-ID: Cc: linux-kernel@vger.kernel.org, hpa@zytor.com, mingo@kernel.org, peterz@infradead.org, hannes@cmpxchg.org, riel@redhat.com, srikar@linux.vnet.ibm.com, aarcange@redhat.com, mgorman@suse.de, tglx@linutronix.de Reply-To: mingo@kernel.org, hpa@zytor.com, linux-kernel@vger.kernel.org, peterz@infradead.org, hannes@cmpxchg.org, riel@redhat.com, srikar@linux.vnet.ibm.com, aarcange@redhat.com, mgorman@suse.de, tglx@linutronix.de In-Reply-To: <1381141781-10992-15-git-send-email-mgorman@suse.de> References: <1381141781-10992-15-git-send-email-mgorman@suse.de> To: linux-tip-commits@vger.kernel.org Subject: [tip:sched/core] sched/numa: Continue PTE scanning even if migrate rate limited Git-Commit-ID: 9e645ab6d089f5822479a833c6977c785bcfffe3 X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (terminus.zytor.com [127.0.0.1]); Wed, 09 Oct 2013 10:26:18 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: 9e645ab6d089f5822479a833c6977c785bcfffe3 Gitweb: http://git.kernel.org/tip/9e645ab6d089f5822479a833c6977c785bcfffe3 Author: Peter Zijlstra AuthorDate: Mon, 7 Oct 2013 11:28:52 +0100 Committer: Ingo Molnar CommitDate: Wed, 9 Oct 2013 12:40:09 +0200 sched/numa: Continue PTE scanning even if migrate rate limited Avoiding marking PTEs pte_numa because a particular NUMA node is migrate rate limited sees like a bad idea. Even if this node can't migrate anymore other nodes might and we want up-to-date information to do balance decisions. We already rate limit the actual migrations, this should leave enough bandwidth to allow the non-migrating scanning. I think its important we keep up-to-date information if we're going to do placement based on it. Signed-off-by: Peter Zijlstra Signed-off-by: Mel Gorman Reviewed-by: Rik van Riel Cc: Andrea Arcangeli Cc: Johannes Weiner Cc: Srikar Dronamraju Link: http://lkml.kernel.org/r/1381141781-10992-15-git-send-email-mgorman@suse.de Signed-off-by: Ingo Molnar --- kernel/sched/fair.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 573d815e..464207f 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -951,14 +951,6 @@ void task_numa_work(struct callback_head *work) */ p->node_stamp += 2 * TICK_NSEC; - /* - * Do not set pte_numa if the current running node is rate-limited. - * This loses statistics on the fault but if we are unwilling to - * migrate to this node, it is less likely we can do useful work - */ - if (migrate_ratelimited(numa_node_id())) - return; - start = mm->numa_scan_offset; pages = sysctl_numa_balancing_scan_size; pages <<= 20 - PAGE_SHIFT; /* MB in pages */