From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout11.his.huawei.com (canpmsgout11.his.huawei.com [113.46.200.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9F3741B425C; Sat, 31 Jan 2026 04:00:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.226 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769832022; cv=none; b=JvSLMLVr7CkUGUNbd455H22Gqf80nFW+6Q8UNgfgtii19MikdZsA74V3WGeLdO/0Eh81DopDDkz4eDVHubm1FQBlFTx1ZlwFZ/+P/jgQG0f/GTCTwR0UXeiNmwG7vcti2ALUMMY30von9cZedVRc6US/GVmOdBMLkWTrzr1DaDQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769832022; c=relaxed/simple; bh=z3tlrUPooP82+V0BbAiKe3K7BUau6mwWfv+4LeX9jC4=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=G+G0eKjAtrN4FJS3tLho2GgCtwCYEUqKDTOcRwccY0nbzVPSJ94eJ+pGUzi74VTXeUUuQNsfgXurvnN0gTHzt+W+JUd+YdBl1uR/u37Xv3K94PC4YecV/YO0lsVaNo9JnSiwvf1SWICTv3WTWdrl0SE0KZWUCKFTazMV2K6JW8I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=5jyf1Gsa; arc=none smtp.client-ip=113.46.200.226 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="5jyf1Gsa" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=3XJedK4MmDnR2JyB787ezHU0nCGdc2HUxXtDSyYjRMA=; b=5jyf1GsaT2tzcC7y9WYys6GjT9+RZCfDyuu3a7E8JV6TN73NbpFPvR8iS+ybQ6CyhRJctlxpj xG1kli3l9Nq6sLvTFdTOJoBxU8VewA/VqebfWHaShlMeB4xcc3m7NcQqfJNwOYOxqOu1cHNoVCJ mLyy0l213rgKOeZy7bdMA+s= Received: from mail.maildlp.com (unknown [172.19.163.163]) by canpmsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4f2zZv2QcwzKm6D; Sat, 31 Jan 2026 11:56:39 +0800 (CST) Received: from kwepemf200001.china.huawei.com (unknown [7.202.181.227]) by mail.maildlp.com (Postfix) with ESMTPS id A9A074048B; Sat, 31 Jan 2026 12:00:09 +0800 (CST) Received: from [10.67.121.90] (10.67.121.90) by kwepemf200001.china.huawei.com (7.202.181.227) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Sat, 31 Jan 2026 12:00:08 +0800 Message-ID: <28f83199-557f-4305-baf5-01fb4fe2cd2c@huawei.com> Date: Sat, 31 Jan 2026 12:00:08 +0800 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 2/6] cpufreq: Add boost_freq_req QoS request To: Pierre Gondois CC: Jie Zhan , Ionela Voinescu , Christian Loehle , , "Rafael J. Wysocki" , Viresh Kumar , Huang Rui , "Gautham R. Shenoy" , Mario Limonciello , Perry Yuan , Srinivas Pandruvada , Len Brown , Saravana Kannan , , References: <20260126101826.94030-1-pierre.gondois@arm.com> <20260126101826.94030-3-pierre.gondois@arm.com> From: "zhenglifeng (A)" In-Reply-To: <20260126101826.94030-3-pierre.gondois@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems200002.china.huawei.com (7.221.188.68) To kwepemf200001.china.huawei.com (7.202.181.227) On 2026/1/26 18:18, Pierre Gondois wrote: > The Power Management Quality of Service (PM QoS) allows to > aggregate constraints from multiple entities. It is currently > used to manage the min/max frequency of a given policy. > > Frequency constraints can come for instance from: > - Thermal framework: acpi_thermal_cpufreq_init() > - Firmware: _PPC objects: acpi_processor_ppc_init() > - User: by setting policyX/scaling_[min|max]_freq > The minimum of the max frequency constraints is used to compute > the resulting maximum allowed frequency. > > When enabling boost frequencies, the same frequency request object > (policy->max_freq_req) as to handle requests from users is used. > As a result, when setting: > - scaling_max_freq > - boost > The last sysfs file used overwrites the request from the other > sysfs file. > > To avoid this, create a per-policy boost_freq_req to save the boost > constraints instead of overwriting the last scaling_max_freq > constraint. > > Signed-off-by: Pierre Gondois > --- > drivers/cpufreq/cpufreq.c | 40 ++++++++++++++++++++++++++++++++++----- > include/linux/cpufreq.h | 1 + > 2 files changed, 36 insertions(+), 5 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index db414c052658b..c8fb4c6656e94 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -1359,17 +1359,24 @@ static void cpufreq_policy_free(struct cpufreq_policy *policy) > /* Cancel any pending policy->update work before freeing the policy. */ > cancel_work_sync(&policy->update); > > - if (policy->max_freq_req) { > + if (policy->max_freq_req || policy->boost_freq_req) { > /* > - * Remove max_freq_req after sending CPUFREQ_REMOVE_POLICY > - * notification, since CPUFREQ_CREATE_POLICY notification was > - * sent after adding max_freq_req earlier. > + * Remove max/boost _freq_req after sending CPUFREQ_REMOVE_POLICY > + * notification, since CPUFREQ_CREATE_POLICY notification was sent > + * after adding max/boost _freq_req earlier. > */ > blocking_notifier_call_chain(&cpufreq_policy_notifier_list, > CPUFREQ_REMOVE_POLICY, policy); As we discussed in [1], CPUFREQ_REMOVE_POLICY notification will be sent here without sending CPUFREQ_CREATE_POLICY notification before if adding boost_freq_req fails. [1] https://lore.kernel.org/all/a615ab13-bd54-4051-ae61-2bfe8b59427e@arm.com/ > - freq_qos_remove_request(policy->max_freq_req); > } > > + if (policy->boost_freq_req) { > + freq_qos_remove_request(policy->boost_freq_req); > + kfree(policy->boost_freq_req); > + } > + > + if (policy->max_freq_req) > + freq_qos_remove_request(policy->max_freq_req); > + Thses two 'if's are unnecessary. It's OK to call freq_qos_remove_request and kfree when the QoS request is NULL. > freq_qos_remove_request(policy->min_freq_req); > kfree(policy->min_freq_req); > > @@ -1479,6 +1486,29 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy, > goto out_destroy_policy; > } > > + if (policy->boost_supported) { > + policy->boost_freq_req = kzalloc(sizeof(*policy->boost_freq_req), > + GFP_KERNEL); > + if (!policy->boost_freq_req) { > + ret = -ENOMEM; > + goto out_destroy_policy; > + } > + > + ret = freq_qos_add_request(&policy->constraints, > + policy->boost_freq_req, > + FREQ_QOS_MAX, > + FREQ_QOS_MAX_DEFAULT_VALUE); > + if (ret < 0) { > + /* > + * So we don't call freq_qos_remove_request() for an > + * uninitialized request. > + */ > + kfree(policy->boost_freq_req); > + policy->boost_freq_req = NULL; > + goto out_destroy_policy; > + } > + } > + > blocking_notifier_call_chain(&cpufreq_policy_notifier_list, > CPUFREQ_CREATE_POLICY, policy); > } > diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h > index 0465d1e6f72ac..c292a6a19e4f5 100644 > --- a/include/linux/cpufreq.h > +++ b/include/linux/cpufreq.h > @@ -81,6 +81,7 @@ struct cpufreq_policy { > struct freq_constraints constraints; > struct freq_qos_request *min_freq_req; > struct freq_qos_request *max_freq_req; > + struct freq_qos_request *boost_freq_req; > > struct cpufreq_frequency_table *freq_table; > enum cpufreq_table_sorting freq_table_sorted;