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 C52B2C07E8F for ; Mon, 22 Apr 2024 07:46:31 +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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=7eQMbjz0KM9Bg5REJoVh40SLasEJeg8ylM3l9S/HEX0=; b=3kahV7XrvrONmJ CcfVB3HL+1w8+dr1JQC0V8b7ubnkqO5353ZRei2bNdi5Tgx90h00PCAZGN5npDxtBBcTXFCmSo9gb E6Xf2f6NQIP6l6+p4D0mi2WT2d5uW/8EOU4s2VA09l0kg5x6rCPQkNShPTf78aJGi3QqaBcQahMud Pew3Z1fIBjaTmzchJRqsZQmHH3DBnSXN/GXONF4BblNXAFTJUkz7h1ZczALeFn/WMW2AmjcBJXgOy VHWYDT+Sl6cyel3cTpGZ1dGAQ5zWXaV/mgAi1Jmx/wPZ2TQsdgWnFPzOjxEEpsXRP3AWj8ywHFlNy 5pain67lRyKKnQrAhjfQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1ryoNa-0000000CUwF-0oZI; Mon, 22 Apr 2024 07:46:22 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1ryoNW-0000000CUuI-1TKF for linux-arm-kernel@lists.infradead.org; Mon, 22 Apr 2024 07:46:20 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2BC79339; Mon, 22 Apr 2024 00:46:43 -0700 (PDT) Received: from [192.168.178.110] (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 32D433F7BD; Mon, 22 Apr 2024 00:46:13 -0700 (PDT) Message-ID: <823cbe86-1615-4c68-9995-ef3565c9e42b@arm.com> Date: Mon, 22 Apr 2024 09:46:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] PM: EM: Add min/max available performance state limits Content-Language: en-US To: Lukasz Luba , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org, sudeep.holla@arm.com, cristian.marussi@arm.com, linux-samsung-soc@vger.kernel.org, rafael@kernel.org, viresh.kumar@linaro.org, quic_sibis@quicinc.com References: <20240403162315.1458337-1-lukasz.luba@arm.com> <20240403162315.1458337-2-lukasz.luba@arm.com> From: Dietmar Eggemann In-Reply-To: <20240403162315.1458337-2-lukasz.luba@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240422_004619_505608_2AE738DD X-CRM114-Status: GOOD ( 20.01 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 03/04/2024 18:23, Lukasz Luba wrote: > On some devices there are HW dependencies for shared frequency and voltage > between devices: CPUs and L3 cache. When the L3 cache frequency is > increased, the affected CPUs might run at higher voltage and frequency. IMHO, this is an example where the min Performance State (PS) makes sense. But what's a use case for the max PS? > That higher voltage causes higher CPU power and thus more energy is used > for running the tasks. > > Add performance state limits which are applied for the device. This allows Regarding device, I thought that this is only applicable for device type CPU? > the Energy Model (EM) to better reflect the CPU's currently available > performance states. This information is used by Energy Aware Scheduler > (EAS) during task placement to avoid situation when a simulated energy > cost has error due to using wrong Power Domain (PD) frequency. Maybe better? This is important on SoCs with HW dependencies mentioned above so that the Energy Aware Scheduler (EAS) does not use performance states outside the valid min-max range for energy calculation. > The function performs only bare minimum checks (and requires EM as s/The function/em_update_performance_limits() s/EM/PD ... I guess we always pass a PD pointer to all the EM functions. I guess we can say that an EM consists of at least 2 PDs. I guess it's valid to say that we limit per PD, e.g. per little CPUs? [...] > /** > * em_pd_get_efficient_state() - Get an efficient performance state from the EM > @@ -189,12 +195,13 @@ int em_dev_update_chip_binning(struct device *dev); > */ Missing min_ps, max_ps description in function header of em_pd_get_efficient_state(). [...] > +/** > + * em_update_performance_limits() - Update Energy Model with performance > + * limits information. > + * @pd : Performance Domain with EM that has to be updated. > + * @freq_min_khz : New minimum allowed frequency for this device. > + * @freq_max_khz : New maximum allowed frequency for this device. > + * > + * This function allows to update the EM with information about available > + * performance levels. It takes the minimum and maximum frequency in kHz > + * and does internal translation to performance levels. > + * Returns 0 on success or -EINVAL when failed. > + */ > +int em_update_performance_limits(struct em_perf_domain *pd, > + unsigned long freq_min_khz, unsigned long freq_max_khz) > +{ > + struct em_perf_state *table; > + int min_ps = -1; > + int max_ps = -1; > + int i; > + > + if (!pd) > + return -EINVAL; > + > + rcu_read_lock(); > + table = em_perf_state_from_pd(pd); > + > + for (i = 0; i < pd->nr_perf_states; i++) { > + if (freq_min_khz == table[i].frequency) So the caller has to know the exact frequency value of the performance states (PSs)? It's not 'f(PS_n-1) + 1 <= x <= f(PS_n)'. [...] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel