Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751440AbdFZPEK (ORCPT ); Mon, 26 Jun 2017 11:04:10 -0400 Received: from merlin.infradead.org ([205.233.59.134]:58364 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750852AbdFZPEG (ORCPT ); Mon, 26 Jun 2017 11:04:06 -0400 Date: Mon, 26 Jun 2017 17:04:01 +0200 From: Peter Zijlstra To: Rik van Riel Cc: linux-kernel@vger.kernel.org, jhladky@redhat.com, mingo@kernel.org, mgorman@suse.de Subject: Re: [PATCH 4/4] sched,fair: remove effective_load Message-ID: <20170626150401.GC4941@worktop> References: <20170623165530.22514-1-riel@redhat.com> <20170623165530.22514-5-riel@redhat.com> <20170626144437.GB4941@worktop> <20170626144611.GA5775@worktop> <1498488941.13083.43.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1498488941.13083.43.camel@redhat.com> User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1028 Lines: 25 On Mon, Jun 26, 2017 at 10:55:41AM -0400, Rik van Riel wrote: > On Mon, 2017-06-26 at 16:46 +0200, Peter Zijlstra wrote: > > On Mon, Jun 26, 2017 at 04:44:37PM +0200, Peter Zijlstra wrote: > > > On Fri, Jun 23, 2017 at 12:55:30PM -0400, riel@redhat.com wrote: > > > > From: Rik van Riel > > > > > > > > The function effective_load was only used by the NUMA balancing > > > > code, and not by the regular load balancing code. Now that the > > > > NUMA balancing code no longer uses it either, get rid of it. > > > > > > Hmm,... funny. It used to be used by wake-affine. I'll have to go > > > check > > > what happened. > > > > Ah, it fell pray to that LLC == NUMA confusion from the previous > > patch. > > > > That really looks buggered. > > Do the changelog or comments of that patch need fixing, > to avoid LLC / NUMA confusion? Neither, I think the code is actually wrong for the case where LLC < NUMA (a somewhat rare case these days, granted, but something that might still happen on !x86 perhaps).