Received: by 2002:a05:7412:8598:b0:f9:33c2:5753 with SMTP id n24csp413507rdh; Tue, 19 Dec 2023 02:52:30 -0800 (PST) X-Google-Smtp-Source: AGHT+IETja6t3qZqCEX5By+dum0vEQxQRQRkjs4U4zb7ctUYjzT41pfUP+H8A/Q9AuckgC6GDDWN X-Received: by 2002:a05:622a:347:b0:425:8abd:f475 with SMTP id r7-20020a05622a034700b004258abdf475mr24307027qtw.69.1702983150045; Tue, 19 Dec 2023 02:52:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702983150; cv=none; d=google.com; s=arc-20160816; b=QsbAW07pZ2KHgyl/d1nvmoug396gEaMI3fsvHtS+KciATNTYUa6auHojUDo50H5BdR 3vvmPhYAly1kWqKuZITDgAjwid8/6C2h9DhYMZsVQeZ2n9Iz+v/cosj4m4dpjo2Kta6j TYapCZNfwZS1JkdWX5509DjX4DfOUWz5H1NcHqtxQ501bVQkiv5od65o0MR0aGMjC0b9 V9U7DmTTTmmXxloLtfoUriHBIb4Y3plbg/99Qz1SX9Da22yeIzyg1g5FQTtFfMIdyPPk Bi/D91bxwjKAwOWKpJBK+o5aZuACjdRWFwzBBCEuwoUm1M2PUKmdzUpCLNUIpg+yYUT/ j9Zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=BjJ+G2YyRbrEE2a1R5+jg4eint7FZpHpZjHjDZzdCP0=; fh=YmW56Jjlaak1EaOYEIddWG8QfZwpR67Ad7p8iQIhC54=; b=azdWRpM0ZOSrXFBrumULnmJLbK1xYbtO0lt6wX1U/h6xa7vrqgfFHlSXQSH6TEkPN9 WdTf1DgmFIY2o5FpeTMCPAuOuCpSydvSM7n8O2YWJK6uxfoOcdCFS4qvlhn84FAH4Vci FXYuthYv1fUYxJKZDKApJ2uIRnpDLroUEXa/7RoOIloz9svzTlAD8Xf40ifJAOmVm/uL V6MxNsRaYaN0tUkknW7t7BNeCzOTjxLGZpmNr8c4yhDs3ynY7KS8SxEgsVP4AOGTI4WU 38/dQg6WurwpuYMdJBwnLO1HZ2++F4qj1EXQOLCNR2TSBzaFdr4r+PjOG3JTORBzKM+T K/7w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-5035-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-5035-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id j16-20020ac85f90000000b004277bdba6cfsi510883qta.182.2023.12.19.02.52.29 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Dec 2023 02:52:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-5035-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-5035-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-5035-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id A8E0C1C21371 for ; Tue, 19 Dec 2023 10:52:29 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 7698E14F78; Tue, 19 Dec 2023 10:52:22 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 23CE314F68; Tue, 19 Dec 2023 10:52:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 8A00F1FB; Tue, 19 Dec 2023 02:53:03 -0800 (PST) Received: from [10.57.85.227] (unknown [10.57.85.227]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0CE713F738; Tue, 19 Dec 2023 02:52:16 -0800 (PST) Message-ID: Date: Tue, 19 Dec 2023 10:53:22 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 03/23] PM: EM: Find first CPU active while updating OPP efficiency Content-Language: en-US To: Qais Yousef Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, rafael@kernel.org, dietmar.eggemann@arm.com, rui.zhang@intel.com, amit.kucheria@verdurent.com, amit.kachhap@gmail.com, daniel.lezcano@linaro.org, viresh.kumar@linaro.org, len.brown@intel.com, pavel@ucw.cz, mhiramat@kernel.org, wvw@google.com References: <20231129110853.94344-1-lukasz.luba@arm.com> <20231129110853.94344-4-lukasz.luba@arm.com> <20231217175829.a6hqz7mqlvrujsvs@airbuntu> From: Lukasz Luba In-Reply-To: <20231217175829.a6hqz7mqlvrujsvs@airbuntu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/17/23 17:58, Qais Yousef wrote: > On 11/29/23 11:08, 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 active CPU from the Performance Domain. This is >> needed since the first CPU in the cpumask might be offline when we >> run this code path. > > I didn't understand the problem here. It seems you're fixing a race, but the > description is not clear to me what the race is. I have explained that in v1, v4 comments for this patch. When the EM is registered the fist CPU is always online. No problem for the old code, but for new code with runtime modification at later time, potentially from different subsystems - it it (e.g. thermal, drivers, etc). The fist CPU might be offline, but still such EM update for this domain shouldn'y fail. Although, when the CPU is offline we cannot get the valid policy... We can get it for next cpu in the cpumask, that's what the code is doing. > >> >> 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 42486674b834..aa7c89f9e115 100644 >> --- a/kernel/power/energy_model.c >> +++ b/kernel/power/energy_model.c >> @@ -243,12 +243,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; >> >> - policy = cpufreq_cpu_get(cpumask_first(em_span_cpus(pd))); >> + /* Try to get a CPU which is active 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); > > Shouldn't policy be NULL here if all policy->realted_cpus were offlined? It will be NULL but we will capture that fact in other way in the 'if' above. We want something else. We want to get policy using 'some' online CPU's id from our known cpumask. Then we can continue with such policy in the code.