From patchwork Wed Dec 7 10:17:03 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lukasz Luba X-Patchwork-Id: 631812 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A46EC352A1 for ; Wed, 7 Dec 2022 10:17:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230308AbiLGKRe (ORCPT ); Wed, 7 Dec 2022 05:17:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45712 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230364AbiLGKR0 (ORCPT ); Wed, 7 Dec 2022 05:17:26 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id DAF0A45EDF; Wed, 7 Dec 2022 02:17:21 -0800 (PST) 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 5D4AB23A; Wed, 7 Dec 2022 02:17:28 -0800 (PST) Received: from e123648.arm.com (unknown [10.57.7.234]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id ADD3F3F73B; Wed, 7 Dec 2022 02:17:18 -0800 (PST) From: Lukasz Luba To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, rafael@kernel.org Cc: lukasz.luba@arm.com, viresh.kumar@linaro.org, dietmar.eggemann@arm.com, vincent.guittot@linaro.org, saravanak@google.com, wusamuel@google.com, isaacmanjarres@google.com, kernel-team@android.com, juri.lelli@redhat.com, peterz@infradead.org, mingo@redhat.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de Subject: [PATCH v2 0/2] cpufreq: schedutil: Optimize operations in hot path frequency switch Date: Wed, 7 Dec 2022 10:17:03 +0000 Message-Id: <20221207101705.9460-1-lukasz.luba@arm.com> X-Mailer: git-send-email 2.17.1 Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Hi all, This v2 is an attempt to optimize some not needed operations in the frequency change code path for the shared freq. domain. There was different approach which was too aggressive and failed do to working on a state CPU capacity information. changes: v2: - split the patch into two (Viresh) v1: - simple approach which fetches CPU capacity every time it's needed, not relaying on the setup value, which was causing issues. Regards, Lukasz Lukasz Luba (2): cpufreq: schedutil: Introduce single max CPU capacity for freqency domain cpufreq: schedutil: Optimize operations with single max CPU capacity kernel/sched/cpufreq_schedutil.c | 35 +++++++++++++++++++------------- 1 file changed, 21 insertions(+), 14 deletions(-) Acked-by: Viresh Kumar