Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp4165558imw; Tue, 12 Jul 2022 03:10:50 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tMAMRIw892BucqXrleYxjTfZJAN6Xme+81oRtJ5dH447ERzK0lgse8eXb89n0MK+2Zgry+ X-Received: by 2002:a17:90a:6c65:b0:1ef:9479:372c with SMTP id x92-20020a17090a6c6500b001ef9479372cmr3331728pjj.21.1657620650302; Tue, 12 Jul 2022 03:10:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657620650; cv=none; d=google.com; s=arc-20160816; b=gN/1hFjtp63VtUkT4oHXKxPupK86i6HlP4cRqM0PHpUyARS2VnkBWQvhSvEnyQAhgF 1JOGDlI3RygAEtWuwv7T3x0l4V3DQEw4jqfjhFSLq/tCoj01OO/ZumjfDVxVlMFd91eG JpLazUOnm9AC4N7zcpoEvkkLZajq6ZCtQXWPmTLQXwdjDQq0VEgmbb+9gh6o7V9ojCwZ 8Tt86jLwHId1wTPb4iUwPnOK1C6u+HxJi9/I1WiyjBPNLl0gpP9mZ8yOR03iG8MvGAxx 7UJ/1qKBPBvXJuFZwiP/ywhjGE17YdQ0x05MwK+bArxOLQAR0hXf/I6OGn1vU/1pfDAh NJQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=BCkG1fn0phesyBKp/Y6KVKSfMYjFC4V93+ZKCJ0dYF8=; b=ietcGHdkRE+2cWuSA3rQSxL6OYcWY8a4AcnhMQw4gshAJYNY4LnPaLjQux2hZ3O/gW AA5cl02/40Eqh2a6p56DyuFnoezfk2sQqXqaZcZg9As6veNYL2h/TtZzTHb5MsJRYPPY plx4LvMqloGt9He9lYegKsPZdF+HxzqL3/ctM3Ytzypvw+Smq54EyJ70cvEj6ja+hL4Y jccDwD1uNmHtp7ANCWVmp+/Hz3Md0yQcc8Z2E1usGzq3R5t4Bl5X3l/tPtJ4+BToR9HT v55dIJIitvD5rhJ/Gn07Ikstgo5qmB1QX1rZAK98O+lSi2tGPXjzUox84iYJKJGhSBqH cQhA== 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 t63-20020a635f42000000b00415c97318c6si13817379pgb.289.2022.07.12.03.10.30; Tue, 12 Jul 2022 03:10:50 -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 S232686AbiGLKHR (ORCPT + 99 others); Tue, 12 Jul 2022 06:07:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54800 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232351AbiGLKHP (ORCPT ); Tue, 12 Jul 2022 06:07:15 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id ED360AAB3E; Tue, 12 Jul 2022 03:07:14 -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 C7D5D1516; Tue, 12 Jul 2022 03:07:14 -0700 (PDT) Received: from [192.168.33.14] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 58EA83F792; Tue, 12 Jul 2022 03:07:13 -0700 (PDT) Message-ID: <20e4ffb8-905a-92e2-8ea2-6116e8031dac@arm.com> Date: Tue, 12 Jul 2022 11:07:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH] cpufreq: schedutil: Move max CPU capacity to sugov_policy Content-Language: en-US To: Viresh Kumar Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, rafael@kernel.org, dietmar.eggemann@arm.com, vincent.guittot@linaro.org References: <20220711124229.16516-1-lukasz.luba@arm.com> <20220712084137.pb24lolhuk2yln4e@vireshk-i7> From: Lukasz Luba In-Reply-To: <20220712084137.pb24lolhuk2yln4e@vireshk-i7> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE 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 On 7/12/22 09:41, Viresh Kumar wrote: > On 11-07-22, 13:42, Lukasz Luba wrote: >> There is no need to keep the max CPU capacity in the per_cpu instance. >> Furthermore, there is no need to check and update that variable >> (sg_cpu->max) everytime in the frequency change request, which is part >> of hot path. Instead use struct sugov_policy to store that information. >> Initialize the max CPU capacity during the setup and start callback. >> We can do that since all CPUs in the same frequency domain have the same >> max capacity (capacity setup and thermal pressure are based on that). >> >> Signed-off-by: Lukasz Luba >> --- >> kernel/sched/cpufreq_schedutil.c | 30 +++++++++++++++--------------- >> 1 file changed, 15 insertions(+), 15 deletions(-) > > I tried to check all possible combinations on how this can break, but > couldn't find one. I had to check that as this code is there since > ages and none of us thought of it, which was surprising. I thought the same. > > Acked-by: Viresh Kumar > Thanks for the ACK!