Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp3405616rwb; Fri, 30 Sep 2022 03:10:14 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4LnWAt+O5eqD6kLBaCkZD2IhSLoiBSh6TjaOW8DoB3NvOJQ4gNlMbydv0nBhajaSESBoEy X-Received: by 2002:a17:907:80a:b0:783:2585:5d73 with SMTP id wv10-20020a170907080a00b0078325855d73mr5976852ejb.642.1664532614468; Fri, 30 Sep 2022 03:10:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664532614; cv=none; d=google.com; s=arc-20160816; b=Mitexxn1F/Pzrtbm9oSARQtS3IzayBpdh1yw4l0XWrzudKEQf1ImBOoh3uIXFF1+Zy Et5TSb6q1SojyVH3PjIE3l2yn6YaF3pST63fnhKMfkZm5KFv9boNIG/oKhWekghPORNd OqUYZAhFVcUiXwHztzEMpdrNpgyJdTo501Y26fIOZ0UUhLtpnbvBtz/cjMDyruBDKnXr imvhye60GP+QZFlOs9DIDazT2BUf4pQhiH4RM6NBlwBIgPzU9Iwj8Q8Ig8lhFfarkCCs m68k03MbZA2qXJZIHgfIPEdUjRd5jpKy1C4BVZOTytSNfNgPBOPMmoAaHC8TtHriORdq HMtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from; bh=Uge4lrNLmGS2r50vO3Wcu3TmZ5Z4KS5bxv9aae9/rXI=; b=gwVDrM14rWC8RAgzBFxPtvPxikrjeRdyiBYz93sxdZCR3FkEPs8sSWbSEfI7rMRLm+ 3SjxFaPEBguzuBILXGhUcB+evpSYS0/7G9QChvUhCe16XOhDjo2AcN88q6EbHMhrwsdy ZMNRcoro9Xas2r4zqlYn18rYKzOn8szweRVtHgG0h4c8/EfSIQQdQPELaEDNzlsB6ZGl rWLdGrhH42Xs9Rj7quAyda0inZ2JVcUMxfIJ46dhgv+BoNLRwGWb5uHblShYHri7dD6J X3lvZVJo++8ayMuvjZBKdXzpya3ckFVWFDMYjHNXk5n/XpZer66y7esVTfFWfp9kqxdU zTpg== 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 w12-20020a056402268c00b004480ab3ded0si1936684edd.228.2022.09.30.03.09.47; Fri, 30 Sep 2022 03:10:14 -0700 (PDT) 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 S229571AbiI3Jss (ORCPT + 99 others); Fri, 30 Sep 2022 05:48:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44760 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231207AbiI3Jsm (ORCPT ); Fri, 30 Sep 2022 05:48:42 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0DEE29F182; Fri, 30 Sep 2022 02:48:41 -0700 (PDT) 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 802C915BF; Fri, 30 Sep 2022 02:48:47 -0700 (PDT) Received: from e123648.arm.com (unknown [10.57.0.185]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 9705F3F73B; Fri, 30 Sep 2022 02:48:39 -0700 (PDT) From: Lukasz Luba To: linux-kernel@vger.kernel.org, rafael@kernel.org Cc: linux-pm@vger.kernel.org, lukasz.luba@arm.com, viresh.kumar@linaro.org, Dietmar.Eggemann@arm.com Subject: [PATCH 2/2] cpufreq: Update CPU capacity reduction in store_scaling_max_freq() Date: Fri, 30 Sep 2022 10:48:21 +0100 Message-Id: <20220930094821.31665-2-lukasz.luba@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20220930094821.31665-1-lukasz.luba@arm.com> References: <20220930094821.31665-1-lukasz.luba@arm.com> 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 When the new max frequency value is stored, the task scheduler must know about it. The scheduler uses the CPUs capacity information in the task placement. Use the existing mechanism which provides information about reduced CPU capacity to the scheduler due to thermal capping. Signed-off-by: Lukasz Luba --- drivers/cpufreq/cpufreq.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 1f8b93f42c76..205d9ea9c023 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -27,6 +27,7 @@ #include #include #include +#include #include #include #include @@ -718,6 +719,8 @@ static ssize_t show_scaling_cur_freq(struct cpufreq_policy *policy, char *buf) static ssize_t store_scaling_max_freq (struct cpufreq_policy *policy, const char *buf, size_t count) { + unsigned int frequency; + struct cpumask *cpus; unsigned long val; int ret; @@ -726,7 +729,20 @@ static ssize_t store_scaling_max_freq return -EINVAL; ret = freq_qos_update_request(policy->max_freq_req, val); - return ret >= 0 ? count : ret; + if (ret >= 0) { + /* + * Make sure that the task scheduler sees these CPUs + * capacity reduction. Use the thermal pressure mechanism + * to propagate this information to the scheduler. + */ + cpus = policy->related_cpus; + frequency = __resolve_freq(policy, val, CPUFREQ_RELATION_HE); + arch_update_thermal_pressure(cpus, frequency); + + ret = count; + } + + return ret; } static ssize_t store_scaling_min_freq -- 2.17.1