From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9E3A0C433F5 for ; Thu, 17 Mar 2022 15:21:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:Cc:To:From :Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Bh0NzO9bzZI3r7EE8G6i86SkarPrsy8M1YWfbSpuAM4=; b=eP4v1rah+brGHAd22rQ/uLqYmA laSl2SoprSM5oP1QxqC0wBrIaTPGoZ4CXpCU76+0dhY0vkpuANDOAV8nnbdJmrfiM1eFkA/ad0rFK SiSdLd8muA7m5HUGd1jb/f6ds1k1BCpDD+OXPDSj801arfOjNnrJ8hJnEj3kyJTssIB/1d1VJsakJ RfBfNcC2Ja+Yj0NQ+zpMUB6d0Ab9Cb7bkKzt2n2iW+LmQ8xRwpyk5HO0MG071dDHfQ7rUTJ/DPfQj lAfDtOUBTj107Y2kQSices5Wt/SQollisDDKbIh8WaSPDpsTDBIZlHFKhuLCDXgn3x2gmCXM9J7mK vOQqu7BQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nUrt3-00GbnC-UE; Thu, 17 Mar 2022 15:18:02 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nUrt0-00GbmV-OM for linux-arm-kernel@lists.infradead.org; Thu, 17 Mar 2022 15:18:00 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 42C0361937; Thu, 17 Mar 2022 15:17:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E413C340E9; Thu, 17 Mar 2022 15:17:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1647530277; bh=iit+kNVt5zpWWwXPYJiPwGesFnvkto/Yc7KjVR9Mkhg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=tyQEo38PMkJ8Fcz5uNbmai5vvlIw0XgS6kAg5D05GCt+d7X5BfyCc+PpYF1iU2QWD OG97uXfq79ulLpRfKSBqM9viv1Dtp1gnsCQ4EnF+szPEQk1gK3hRluac8oo+LHDbYC VLnhpVj39kBL44dlWty5V6NN72lU7wAnLCwWyNBgNoo1t7JXW8yc/Phd/rbz4MQrlg wovOnFYsiyMRt+gRO+mhvRpuQ38cUoKcts9ess7FLhv77w85VE5yh5rNOT7ta0hxgg dvph5vdCelHBSF6z6z89fCsjaYyItggAblKWuaoBBMn6+Lv9mHHiEnwXLP3v8mOAUM v0zkOPpG62xcQ== Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nUrsx-00FDcZ-2F; Thu, 17 Mar 2022 15:17:55 +0000 MIME-Version: 1.0 Date: Thu, 17 Mar 2022 15:17:54 +0000 From: Marc Zyngier To: Pierre Gondois Cc: linux-kernel@vger.kernel.org, Ionela.Voinescu@arm.com, Lukasz.Luba@arm.com, Morten.Rasmussen@arm.com, Dietmar.Eggemann@arm.com, mka@chromium.org, daniel.lezcano@linaro.org, Catalin Marinas , Will Deacon , "Rafael J. Wysocki" , Viresh Kumar , Mark Rutland , Ard Biesheuvel , Fuad Tabba , Rob Herring , linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org Subject: Re: [PATCH v1 1/3] cpufreq: CPPC: Add cppc_cpufreq_search_cpu_data In-Reply-To: <76a15179-560f-d412-1512-7ec28ea62cd9@arm.com> References: <20220317133419.3901736-1-Pierre.Gondois@arm.com> <20220317133419.3901736-2-Pierre.Gondois@arm.com> <746641141c630dc1d02943d6133a6c8d@kernel.org> <76a15179-560f-d412-1512-7ec28ea62cd9@arm.com> User-Agent: Roundcube Webmail/1.4.13 Message-ID: <2741f16d17d646fb84ec96334265ef01@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: pierre.gondois@arm.com, linux-kernel@vger.kernel.org, Ionela.Voinescu@arm.com, Lukasz.Luba@arm.com, Morten.Rasmussen@arm.com, Dietmar.Eggemann@arm.com, mka@chromium.org, daniel.lezcano@linaro.org, catalin.marinas@arm.com, will@kernel.org, rafael@kernel.org, viresh.kumar@linaro.org, mark.rutland@arm.com, ardb@kernel.org, tabba@google.com, robh@kernel.org, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220317_081758_901574_DCBCE656 X-CRM114-Status: GOOD ( 19.06 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2022-03-17 14:44, Pierre Gondois wrote: > On 3/17/22 15:20, Marc Zyngier wrote: >> On 2022-03-17 13:34, Pierre Gondois wrote: >>> cppc_cpufreq_get_cpu_data() allocates a new struct cppc_cpudata >>> for the input CPU at each call. >>> >>> To search the struct associated with a cpu without allocating >>> a new one, add cppc_cpufreq_search_cpu_data(). >>> Also add an early prototype. >>> >>> This will be used in a later patch, when generating artificial >>> performance states to register an artificial Energy Model in the >>> cppc_cpufreq driver and enable the Energy Aware Scheduler for ACPI >>> based systems. >>> >>> Signed-off-by: Pierre Gondois >>> --- >>> drivers/cpufreq/cppc_cpufreq.c | 15 +++++++++++++++ >>> 1 file changed, 15 insertions(+) >>> >>> diff --git a/drivers/cpufreq/cppc_cpufreq.c >>> b/drivers/cpufreq/cppc_cpufreq.c >>> index 82d370ae6a4a..8f950fe72765 100644 >>> --- a/drivers/cpufreq/cppc_cpufreq.c >>> +++ b/drivers/cpufreq/cppc_cpufreq.c >>> @@ -41,6 +41,8 @@ >>> */ >>> static LIST_HEAD(cpu_data_list); >>> >>> +static struct cppc_cpudata *cppc_cpufreq_search_cpu_data(unsigned >>> int >>> cpu); >>> + >>> static bool boost_supported; >>> >>> struct cppc_workaround_oem_info { >>> @@ -479,6 +481,19 @@ static void cppc_cpufreq_put_cpu_data(struct >>> cpufreq_policy *policy) >>> policy->driver_data = NULL; >>> } >>> >>> +static inline struct cppc_cpudata * >> >> Why the inline? This is hardly performance critical, and if >> it is, you want something better than iterating over a list. > > This was made inline mainly because the function was small. The > function > is called only at boot, so it should not be performance critical. The > 'inline' can be removed if necessary. > Would letting it inlined have a negative impact ? This is why we have a compiler. It is perfectly able to decide on its own whether to inline or not, depending on how it can optimise it. With modern compilers, 'inline' means nothing anyway, and is ignored most of the time. So dropping it will at least save 7 bytes of source code! ;-) M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel