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 039A9CD1288 for ; Wed, 3 Apr 2024 16:23:41 +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:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=F0VF4F0vZcl2xppXPxfHH/EK4ynMqkUHDZ2MGf3YJfk=; b=Yq/SDa3jhb8bDr BffWhmQvOtGm5nmpcEbevliE9qNycfZaPhcFCSg+4yYGBWA9N+0wTwaA1Jpsg2F0sQNiMJ0aHkPwC FR1J9udnUMQuQ4hFlUco1snsg0w6oUPi3hwKzz0ln68N6nH3hLLeCKTpL3Zy4Vpj1QzSgmgblM64d /b8xxperJHYxILnSpxRnzN0jiYnAYyC42oAr3iEvxnnsc2+yhfWsw600zJkFe6iM+v55joG3peOf+ f4hM8Wa9jWIOYTgoBIeve0BLJiyKDKWEEiSBiEjprNFy3cRdSE38xaq4Ja/oel6Y5enWA1oUK+yLr 24yBMcML0D/7BR3BtQ1g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rs3Ob-0000000Gwlv-2YEU; Wed, 03 Apr 2024 16:23:29 +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 1rs3OW-0000000Gwja-42aN for linux-arm-kernel@lists.infradead.org; Wed, 03 Apr 2024 16:23:27 +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 EE3731007; Wed, 3 Apr 2024 09:23:52 -0700 (PDT) Received: from e129166.arm.com (unknown [10.57.72.191]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 0CD063F7B4; Wed, 3 Apr 2024 09:23:19 -0700 (PDT) From: Lukasz Luba To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Cc: lukasz.luba@arm.com, dietmar.eggemann@arm.com, 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 Subject: [PATCH 0/2] Update Energy Model with perfromance limits Date: Wed, 3 Apr 2024 17:23:13 +0100 Message-Id: <20240403162315.1458337-1-lukasz.luba@arm.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240403_092325_078430_292B06B6 X-CRM114-Status: GOOD ( 10.38 ) 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 Hi all, This patch set allows to specify in the EM the range of performance levels that the device is allowed to operate. It will impact EAS decision, especially for SoCs where CPUs share the voltage & frequency domain with other CPUs or devices e.g. - Mid CPUs + Big CPU - Little CPU + L3 cache in DSU The minimum allowed frequency will be taken into account while doing EAS task placement simulation. When the min frequency is higher for the whole domain and not driven by the CPUs in that PD utilization, than the energy for computation in that PD will be higher. This patch helps to reflect that higher cost. More explanation can be found in my presentation on OSPM2023 [1]. I have shown experiments with Big CPU running high frequency and increasing the L3 cache frequency (to reduce the latency), but that impacted Little CPU which are in the same DVFS domain with L3 cache. It had bad impact for total energy consumed by small tasks placed on Little CPU. The EAS was not aware about the min frequency&voltage of the Little CPUs and energy estimation was wrong. Depends on: patch 2/2: - SCMI cpufreq performance limits notification support (w/ other dependency) [2] patch 1/2: - EM recent patches for chip binning update - to avoid conflict [3] Therefore, the patch 1/2 could go first and patch 2/2 can wait longer. Regards, Lukasz Luba [1] https://www.youtube.com/watch?v=2C-5uikSbtM&list=PL0fKordpLTjKsBOUcZqnzlHShri4YBL1H [2] https://lore.kernel.org/lkml/20240328074131.2839871-1-quic_sibis@quicinc.com/ [3] https://lore.kernel.org/lkml/20240403154907.1420245-1-lukasz.luba@arm.com/ Lukasz Luba (2): PM: EM: Add min/max available performance state limits cpufreq: scmi: Update Energy Model with allowed performance limits drivers/cpufreq/scmi-cpufreq.c | 19 +++++++++++--- include/linux/energy_model.h | 22 +++++++++++++--- kernel/power/energy_model.c | 48 ++++++++++++++++++++++++++++++++++ 3 files changed, 82 insertions(+), 7 deletions(-) -- 2.25.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel