Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp1719752rwd; Mon, 15 May 2023 01:57:31 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6Da2TL/xqew6SDc0KB9BmZx1akzRkcWbusqGotq7340cfrZxzIDi2XfDD66J1sXKQpDdcW X-Received: by 2002:a17:90b:3504:b0:24e:4b02:4f0 with SMTP id ls4-20020a17090b350400b0024e4b0204f0mr32008184pjb.6.1684141051355; Mon, 15 May 2023 01:57:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684141051; cv=none; d=google.com; s=arc-20160816; b=aRDDjblKKXXYX+PApTBMJiKOjmnV2QsPSYqyPVfXU+MHqFGzocECumlcKy4hueS6nx ygqIHuUTYEYfh4K13UKUag4vHy8A557mruvOh38pLZOeydxzb1zqng0xJEowoMSM0/w9 WBn3aaPmaC5HkFIvb12v7uhWvCE6nY1yww0TjJSbjx3WB8WDga1T2f/E7sx3f5sqeKYY 6dEEKVj+Oq+ji3wpa7SU2Jg92Y4uI7ZrtDJvEDd+4/FZkTBPPmvdpCjbtoUSHIaQYa/t 7XciC0MEvraz2TcNrZ6Ud3K5VUOiXg02icgHvMWs+M2RFdi65gapwjl/5NFJOB02q6qP 0gyg== 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 :content-language:references:cc:to:subject:from:user-agent :mime-version:date:message-id; bh=QMetOZbZqapVgifncWH/mtU7pQyOkQD+UK8n72fJEBI=; b=IIxDBNYw5+XTOM8KvQwbqSCWqpPe6iU3cn+mdtMabC0diwe+gzwMHyvUFesXjf5Eqy OxzJ5T6il7PQkurdqkOD08O9Ixk9SR37tcPKWaqzCn/h4tIQ0y4JnUcp8cg1P5E6y9LW PUgzK0TH70Qa7vnKJ2SvsjzRJ8g11dz9pX0p0uwKUx5EfFvW1v2WmDhkKX+LAEy2Skto F1D/aSuIoPrQHjoajQ8V24BCzQqashQScL0JuNR+G360qxmfN9ZFm/wGOBjPQ2hf9dWY g6U7cvtG9PQ7dqWH7+Jxl+IdGf8o+J53l41TFAfIFCbgoiUOCqeTrpTUNsqagVRU4PhS up4Q== 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 u6-20020a17090adb4600b002474fcf3bdasi25695525pjx.146.2023.05.15.01.57.18; Mon, 15 May 2023 01:57:31 -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 S235912AbjEOIrz (ORCPT + 99 others); Mon, 15 May 2023 04:47:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60990 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237581AbjEOIrx (ORCPT ); Mon, 15 May 2023 04:47:53 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 3DE8BE49; Mon, 15 May 2023 01:47:52 -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 9BC402F4; Mon, 15 May 2023 01:48:36 -0700 (PDT) Received: from [192.168.1.12] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 89EBE3F67D; Mon, 15 May 2023 01:47:48 -0700 (PDT) Message-ID: <9a69f5ae-86a1-5bd4-4564-e257fe64c826@arm.com> Date: Mon, 15 May 2023 10:47:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 From: Pierre Gondois Subject: Re: [PATCH 02/17] PM: EM: Find first CPU online while updating OPP efficiency To: Lukasz Luba Cc: dietmar.eggemann@arm.com, rui.zhang@intel.com, rafael@kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, amit.kucheria@verdurent.com, amit.kachhap@gmail.com, daniel.lezcano@linaro.org, viresh.kumar@linaro.org, len.brown@intel.com, pavel@ucw.cz, ionela.voinescu@arm.com, rostedt@goodmis.org, mhiramat@kernel.org References: <20230314103357.26010-1-lukasz.luba@arm.com> <20230314103357.26010-3-lukasz.luba@arm.com> <0cda1fc9-2e99-66a2-b833-fe5be676d815@arm.com> Content-Language: en-US In-Reply-To: <0cda1fc9-2e99-66a2-b833-fe5be676d815@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,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 Hi Lukasz, On 5/10/23 09:08, Lukasz Luba wrote: > > > On 4/11/23 16:40, Pierre Gondois wrote: >> Hello Lukasz, >> >> On 3/14/23 11:33, Lukasz Luba wrote: >>> The Energy Model might be updated at runtime and the energy efficiency >>> for each OPP may change. Thus, there is a need to update also the >>> cpufreq framework and make it aligned to the new values. In order to >>> do that, use a first online CPU from the Performance Domain. >>> >>> Signed-off-by: Lukasz Luba >>> --- >>>   kernel/power/energy_model.c | 11 +++++++++-- >>>   1 file changed, 9 insertions(+), 2 deletions(-) >>> >>> diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c >>> index 265d51a948d4..3d8d1fad00ac 100644 >>> --- a/kernel/power/energy_model.c >>> +++ b/kernel/power/energy_model.c >>> @@ -246,12 +246,19 @@ em_cpufreq_update_efficiencies(struct device >>> *dev, struct em_perf_state *table) >>>       struct em_perf_domain *pd = dev->em_pd; >>>       struct cpufreq_policy *policy; >>>       int found = 0; >>> -    int i; >>> +    int i, cpu; >>>       if (!_is_cpu_device(dev) || !pd) >>>           return; >> >> Since dev is a CPU, I think it shouldn be possible to get the cpu id via >> 'dev->id'. >> If so the code below should not be necessary anymore. > > When you look at the code it does two things. > It tries to get the CPU id - this might be similar to what you > have proposed with the 'dev->id' but it's also looking at CPUs > which are 'active'. The 'dev' that we have might come from > some place, e.g. thermal cooling, which had a first CPU in > the domain stored somewhere. That CPU might be sometimes > not active, but the rest of the CPUs in the domain might be > running. We have to find an active CPU id and then we get the > 'policy'. It seems that all the call chains look like (the first argument is important): em_dev_register_perf_domain(get_cpu_device(policy->cpu), ...) \-em_cpufreq_update_efficiencies() Whenever a CPU is unplugged in cpufreq, a new CPU is put in charge of the policy (cf. __cpufreq_offline(), policy->cpu is updated). So the 'dev' that em_cpufreq_update_efficiencies() receives should be an active device, with no need to check that the device is active. This would be just an optimization, the present code seems also valid to me. Another NIT, I saw a cpumask_copy() in energy_model.c, but no free_cpumask_var(). This could be done separately from this patchset (if relevant). Regards, Pierre > >> >>> -    policy = cpufreq_cpu_get(cpumask_first(em_span_cpus(pd))); >>> +    /* Try to get a CPU which is online and in this PD */ >>> +    cpu = cpumask_first_and(em_span_cpus(pd), cpu_active_mask); >>> +    if (cpu >= nr_cpu_ids) { >>> +        dev_warn(dev, "EM: No online CPU for CPUFreq policy\n"); >>> +        return; >>> +    } >>> + >>> +    policy = cpufreq_cpu_get(cpu); >>>       if (!policy) { >>>           dev_warn(dev, "EM: Access to CPUFreq policy failed"); >>>           return; >> >> Regards, >> Pierre