From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751544AbdFZPU6 (ORCPT ); Mon, 26 Jun 2017 11:20:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46686 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751302AbdFZPU4 (ORCPT ); Mon, 26 Jun 2017 11:20:56 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3C65380F97 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=riel@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 3C65380F97 Message-ID: <1498490454.13083.45.camel@redhat.com> Subject: Re: [PATCH 4/4] sched,fair: remove effective_load From: Rik van Riel To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, jhladky@redhat.com, mingo@kernel.org, mgorman@suse.de Date: Mon, 26 Jun 2017 11:20:54 -0400 In-Reply-To: <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> <20170626150401.GC4941@worktop> Organization: Red Hat, Inc Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 26 Jun 2017 15:20:56 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2017-06-26 at 17:04 +0200, Peter Zijlstra wrote: > 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). Oh, indeed. I guess in wake_affine() we should test whether the CPUs are in the same NUMA node, rather than doing cpus_share_cache() ? Or, alternatively, have an update_numa_stats() variant for numa_wake_affine() that works on the LLC level?