Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp6204943pxb; Tue, 16 Feb 2021 20:39:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJzIId7Lv53jynr27DzgAGCb+92OP1r1HCr9LnIhP961Y2MW5gVpGGdcImlFELIC40iWq05u X-Received: by 2002:a17:906:128e:: with SMTP id k14mr23234882ejb.427.1613536796926; Tue, 16 Feb 2021 20:39:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613536796; cv=none; d=google.com; s=arc-20160816; b=xrjq3nQvourvAyjoWqJIgSkgmPILNPildbRrVrlp1xPRiIiCHRbibhAm7H9V4OPg7Y rZ2Qed+PoKHjl/sC3ZfZWZPSK0MdM2My3J08trPphagM5lRxOErGW/mx00fxxQPSwoeX ZAahVOo+2Ioq4zTCM37jWenj8kY4BL+3xV5k95d+3cY6JjhdipB3CS62SwbNpGaQQloL vIDRIVorXimWqW2k+suaArp3BpgXx1WJTesls4u+XZm8hPAVuzKY7Z36+gUvWU1bF18t mbGk2wKatCZL5nylk1rl+fUMieOr7Tny4IuAKWTNPFIq3/Bv8yiH1WfxsBzPCqghTG/M i/NQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=YzQ3Ntnx2eFZZBEtRSvFqcJub5kYZcaEUuwH2LgukfU=; b=KFlnV/FtvYPq6KjuupAIQfkCsATYDE1Y7PVue6oJihu5UGG0fP/qAXSo8/WKU/LLjN 1+m03BqjF9tTaCQ+9bwisRSrA1wNcnQtR6mhuwXttGK4dBFPUiwLSEwzsiMDtiyEmBO5 /NdzGRn88iNF6PB/RTkBAAMOUyO60SzjTiougkBLGQUGpJ9qegb5Nzx8As1EVUYiyHTo qsyxw45V7Jt+YIdG8vWv3SOIF3gQirHeFV4HEe7n7mX40ptGToeRDPErS7F7FVT9kWWj LczfH0rVrieSB8fBSjqyLNRS0fzyj95ixgjDKz83LIJWYEZ1NYb50AIMeVgoptocajGB Ft9w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=GF54HJeq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y8si501479edp.207.2021.02.16.20.39.34; Tue, 16 Feb 2021 20:39:56 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=GF54HJeq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231287AbhBQEeK (ORCPT + 99 others); Tue, 16 Feb 2021 23:34:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230401AbhBQE0m (ORCPT ); Tue, 16 Feb 2021 23:26:42 -0500 Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 96748C061786 for ; Tue, 16 Feb 2021 20:26:02 -0800 (PST) Received: by mail-pj1-x1033.google.com with SMTP id cl8so768243pjb.0 for ; Tue, 16 Feb 2021 20:26:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=YzQ3Ntnx2eFZZBEtRSvFqcJub5kYZcaEUuwH2LgukfU=; b=GF54HJeqkRyhzQ+s1UuFr+w4WNWreO8HkCTv0fjuc8ieF4Vuv1uG68W2aMLLLYVkDL 27rv7civIAcFkIQZkHqqknj/dKZ2FNRM+hR+6dtEhwLXINCkAG/6BYMDcfvzQSHGYgy6 nxm4+W7b9nypIGbXtoM0RMQUAAyiUNJNyFlzAXX31eP6kPVkLReHqNsR22vw7f7wr/ti 9U/Mbq+z/QrGmUUEKZrsjFVM4G4OJv04m9BGogx3DGwPTtrw3C3orl5A0nNx+5jAEdE7 +MQHhq3fIwc6Ydgyr7ygK0QVnCVkVQU6Rjmpi1ObI1WizR4NuDQ2FmWaDhg2lxXpr+0V 87ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=YzQ3Ntnx2eFZZBEtRSvFqcJub5kYZcaEUuwH2LgukfU=; b=Jc3/hVgTd5UQRCLZuM6qQiqb0BDUT/wATU8dCpsgmsF3YHLBsf20Va7ELcbpgS4maW /FioEl8CLFXbahlv+DLo8vuGag/97raLY1yDZPFReooo+D0sJiHw3x2aN67U6OxhleEE LN/pQ8YmAMDMcsYDyM1ARfmIYmwBDnPPrOSVG7xWa2vkJjCxpgt65tfK+rkpg8iZOBba vJbiZSKQSTRhkZg1t0ZUWhv+5gdxW37b/ldQo5fZv7GyX00oMXz3V21uCZsDqpyu3Wf/ 0zVXqAaFH0rABix0OQUfWyGRGAWIS4ZC98Fnp8fjU5xNLBDS6g6XEUwZA7UO1bpB2aSk TWZw== X-Gm-Message-State: AOAM533es7EZVQln6DcdDH2delwM+kXHQ7HSicE3xtaeqmHVZmldx8Pf YmrRO8FjcFbcz53z+z5Y4U3eoA== X-Received: by 2002:a17:90b:3781:: with SMTP id mz1mr7396744pjb.178.1613535962017; Tue, 16 Feb 2021 20:26:02 -0800 (PST) Received: from localhost ([122.172.59.240]) by smtp.gmail.com with ESMTPSA id t17sm695687pgk.25.2021.02.16.20.26.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Feb 2021 20:26:01 -0800 (PST) Date: Wed, 17 Feb 2021 09:55:58 +0530 From: Viresh Kumar To: Ionela Voinescu Cc: Rafael Wysocki , Catalin Marinas , Will Deacon , Vincent Guittot , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, Sudeep Holla , Greg Kroah-Hartman Subject: Re: [PATCH V3 1/2] topology: Allow multiple entities to provide sched_freq_tick() callback Message-ID: <20210217042558.o4anjdkayzgqny55@vireshk-i7> References: <20210203114521.GA6380@arm.com> <20210205091424.3od3tme3f7mh7ebp@vireshk-i7> <20210217002422.GA17422@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210217002422.GA17422@arm.com> User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17-02-21, 00:24, Ionela Voinescu wrote: > I think it could be merged in patch 1/2 as it's part of enabling the use > of multiple sources of information for FIE. Up to you! Sure. > > static void amu_fie_setup(const struct cpumask *cpus) > > { > > - bool invariant; > > int cpu; > > > > /* We are already set since the last insmod of cpufreq driver */ > > @@ -257,25 +256,10 @@ static void amu_fie_setup(const struct cpumask *cpus) > > > > cpumask_or(amu_fie_cpus, amu_fie_cpus, cpus); > > > > - invariant = topology_scale_freq_invariant(); > > - > > - /* We aren't fully invariant yet */ > > - if (!invariant && !cpumask_equal(amu_fie_cpus, cpu_present_mask)) > > - return; > > - > > You still need these checks, otherwise you could end up with only part > of the CPUs setting a scale factor, when only part of the CPUs support > AMUs and there is no cpufreq support for FIE. Both supports_scale_freq_counters() and topology_scale_freq_invariant() take care of this now and they will keep reporting the system as invariant until the time all the CPUs have counters (in absence of cpufreq). The topology_set_scale_freq_source() API is supposed to be called multiple times, probably once for each policy and so I don't see a need of these checks anymore. > Small(ish) optimisation at the beginning of this function: > > if (cpumask_empty(&scale_freq_counters_mask)) > scale_freq_invariant = topology_scale_freq_invariant(); > > This will save you a call to rebuild_sched_domains_energy(), which is > quite expensive, when cpufreq supports FIE and we also have counters. Good Point. > After comments addressed, > > Reviewed-by: Ionela Voinescu Thanks. > Tested-by: Ionela Voinescu Just out of curiosity, what exactly did you test and what was the setup ? :) -- viresh