From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752165AbbEZUaC (ORCPT ); Tue, 26 May 2015 16:30:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60690 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751417AbbEZUaA (ORCPT ); Tue, 26 May 2015 16:30:00 -0400 Message-ID: <5564D7A7.6000403@redhat.com> Date: Tue, 26 May 2015 16:29:27 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Artem Bityutskiy CC: linux-kernel@vger.kernel.org, mgorman@suse.de, peterz@infradead.org, jhladky@redhat.com Subject: Re: [PATCH] numa,sched: only consider less busy nodes as numa balancing destination References: <1430908530.7444.145.camel@sauron.fi.intel.com> <20150506114128.0c846a37@cuia.bos.redhat.com> In-Reply-To: <20150506114128.0c846a37@cuia.bos.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/06/2015 11:41 AM, Rik van Riel wrote: > On Wed, 06 May 2015 13:35:30 +0300 > Artem Bityutskiy wrote: > >> we observe a tremendous regression between kernel version 3.16 and 3.17 >> (and up), and I've bisected it to this commit: >> >> a43455a sched/numa: Ensure task_numa_migrate() checks the preferred node > > Artem, Jirka, does this patch fix (or at least improve) the issues you > have been seeing? Does it introduce any new regressions? > > Peter, Mel, I think it may be time to stop waiting for the impedance > mismatch between the load balancer and NUMA balancing to be resolved, > and try to just avoid the issue in the NUMA balancing code... Peter, I got some more test results in. This patch can supercede 095bebf61a46 ("sched/numa: Do not move past the balance point if unbalanced"), which can be reverted. With this patch, a workload that has one (misplaced) thread running, and nothing else on the system, is able to move to the node where its memory is, which is something that 095bebf61a46 prevented. It also fixes the single instance SpecJBB2005 spreading issue, which benefited some (but not completely) from 095bebf61a46 in the past. Peter, what would you like me to do to get this patch into your tree, and 095bebf61a46 reverted? :) -- All rights reversed