From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756739AbbFPR0y (ORCPT ); Tue, 16 Jun 2015 13:26:54 -0400 Received: from e28smtp05.in.ibm.com ([122.248.162.5]:42564 "EHLO e28smtp05.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751057AbbFPR0q (ORCPT ); Tue, 16 Jun 2015 13:26:46 -0400 X-Helo: d28dlp01.in.ibm.com X-MailFrom: srikar@linux.vnet.ibm.com X-RcptTo: linux-kernel@vger.kernel.org Date: Tue, 16 Jun 2015 22:56:39 +0530 From: Srikar Dronamraju To: Rik van Riel Cc: Ingo Molnar , Peter Zijlstra , linux-kernel@vger.kernel.org, Mel Gorman Subject: Re: [PATCH v2 4/4] sched:Use correct nid while evaluating task weights Message-ID: <20150616172639.GB1976@linux.vnet.ibm.com> Reply-To: Srikar Dronamraju References: <1434455762-30857-1-git-send-email-srikar@linux.vnet.ibm.com> <1434455762-30857-5-git-send-email-srikar@linux.vnet.ibm.com> <55803A02.6050204@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <55803A02.6050204@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15061617-0017-0000-0000-000005AEE5D1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Rik van Riel [2015-06-16 11:00:18]: > On 06/16/2015 07:56 AM, Srikar Dronamraju wrote: > > In task_numa_migrate(), while evaluating other nodes for group > > consolidation, env.dst_nid is used instead of using the iterator nid. > > Using env.dst_nid would mean dist is always the same. Infact the same > > dist was calculated above while evaluating the preferred node. > > > > Fix the above to use the iterator nid. > > Good catch. > > > Also the task/group weights from the src_nid should be calculated > > irrespective of numa topology type. > > If you look at score_nearby_nodes(), you will see that > maxdist is only used when the topology is NUMA_BACKPLANE. > > The source score never changes when having a directly > connected or NUMA_GLUELESS_MESH type system, so the source > score does not need to be recalculated unless we are actually > dealing with a NUMA_BACKPLANE topology. > > Looking forward to a v2 with just the first fix. Okay, will fix accordingly. -- Thanks and Regards Srikar Dronamraju