Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp586230rwb; Wed, 7 Dec 2022 02:26:24 -0800 (PST) X-Google-Smtp-Source: AA0mqf73MM6Yf8w1Ss9ryzZcXFK8/9zecKVKlsUOEn2fbQGWB1pF05zQjWPO48AZt4RxkiUbi/wb X-Received: by 2002:a17:90b:3641:b0:219:d636:e5de with SMTP id nh1-20020a17090b364100b00219d636e5demr14693740pjb.134.1670408783953; Wed, 07 Dec 2022 02:26:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670408783; cv=none; d=google.com; s=arc-20160816; b=fiXimNIHWdHnJV/RpIJIwIN+PolhWZnpPgUhzzFLWyOIvHNzqGcWW7q8ovGNUU1r4L BMAunw4AftTBJAyN8sc2mKVdJEzb1/2jS/FKj7BW2li+her06adyrsI+e4ccASyowyrM iSKOJq7ha3sbOewAuVs12cr9VGN5XpY0U7CIgxmqEEIrSWXKDXoRkZsJd3GEqmVWZKaY ZjVsfnCx8A9F6vRvtfYDBbNRhpaEImkR6A/Vyo8nrlsJHx/42NwTNyo2Ayt2yRRbvYeK xtgkJrIb8HBQi8Ts9V24yFw9SM02uwJd3pU5nSNbLJtf5PBIgxUvTMWpNqKbg2aQE3Mt AYbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from; bh=VluWogsjYzXYMttfclHGyI2XmvinXqbjy836kWp8d1M=; b=xEGI571wJucwSjYAt5Yf9Lqp6J7SMmbOUiOLNZb6lRuAs6TCEI849lBeSy4VEOum9J NcrJSWnr76v5OMOU1u8LYybYz1bggPDt7xMBSmqlBwmqUGMLeP1ZqKslUWm956ynPUdC BjBXBZWPFpFFAn6KbqppUpa5Xkg/Vlvs4+5+sxEIALGpFGva1ekVNQC2dj2LY6gBFJ/D IoQDkNsHCxW19Vc0q45JPUFKYuA3MIHFjOG9beIXiL1O6mousKQ3+53YlpBkKhEvFcz3 esH0WAjVJDi3Mb2ClScr3naaMGw48wwyzaEorOwxrMK/2I1CFkliYFfa7GRiihmLjBG6 ZyfA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x71-20020a63864a000000b00478a7598e46si11038939pgd.806.2022.12.07.02.26.14; Wed, 07 Dec 2022 02:26:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230372AbiLGKRg (ORCPT + 77 others); Wed, 7 Dec 2022 05:17:36 -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 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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(-) -- 2.17.1