From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 49EC7250C15; Tue, 29 Apr 2025 17:15:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745946945; cv=none; b=RCMrZgImuEXgxJcjlU3SluRKGa6tyZeupkD60yNlRrsJ9AmDS4CobqaYgJvG013twSRj4HNV+jROWEOsgsvqBqgc7Hf6BFkbdUGfV7kLgzyhTQRoFggP5/2e/teD6nlSSUPX6xOK4gM0/hYW+V5MfUafiiVttYKPgGusUwb6smI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745946945; c=relaxed/simple; bh=VXBvA0+FaDkRWMEitkoYgbTT0wEMpgvPO8tITebQ8tI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LmgY5ak6rlQiTS97ihvHyaMgYNUzEa3vBc7KV7/SG6UcmOsjh7NGu7jgCqsJMCpmiLI5YXv+VqQeKCFIvSwNprD2Nh7cZ7dZr9gMxkQfDLysr8R1h3YTpw1BgJ9mM7+5DtJoubt8VpJwbD6LaLgcmLYwdwhnpS6yDlI9ybQxu6A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=Ivn4A7sG; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="Ivn4A7sG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C04BBC4CEE3; Tue, 29 Apr 2025 17:15:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1745946945; bh=VXBvA0+FaDkRWMEitkoYgbTT0wEMpgvPO8tITebQ8tI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ivn4A7sG+KfGfj2pmeTu3tc+m13T9+CsqECXaaiwR2ZkjI90Yp/CGrgfYyHhT4ZL8 2+9KGnEkBB9p6IZLNzcVs1xozs1ERLiKdscnRFIGHTSJxQz8+OWUSARor0QM2Lnv51 8AkRw9cAi7RU/1Vnc65OM3B6oN5gYd99HhR85vRI= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Stephan Gerhold , "Rafael J. Wysocki" , Christian Loehle , Sasha Levin Subject: [PATCH 5.10 120/286] cpufreq/sched: Fix the usage of CPUFREQ_NEED_UPDATE_LIMITS Date: Tue, 29 Apr 2025 18:40:24 +0200 Message-ID: <20250429161112.794258965@linuxfoundation.org> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250429161107.848008295@linuxfoundation.org> References: <20250429161107.848008295@linuxfoundation.org> User-Agent: quilt/0.68 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Rafael J. Wysocki [ Upstream commit cfde542df7dd51d26cf667f4af497878ddffd85a ] Commit 8e461a1cb43d ("cpufreq: schedutil: Fix superfluous updates caused by need_freq_update") modified sugov_should_update_freq() to set the need_freq_update flag only for drivers with CPUFREQ_NEED_UPDATE_LIMITS set, but that flag generally needs to be set when the policy limits change because the driver callback may need to be invoked for the new limits to take effect. However, if the return value of cpufreq_driver_resolve_freq() after applying the new limits is still equal to the previously selected frequency, the driver callback needs to be invoked only in the case when CPUFREQ_NEED_UPDATE_LIMITS is set (which means that the driver specifically wants its callback to be invoked every time the policy limits change). Update the code accordingly to avoid missing policy limits changes for drivers without CPUFREQ_NEED_UPDATE_LIMITS. Fixes: 8e461a1cb43d ("cpufreq: schedutil: Fix superfluous updates caused by need_freq_update") Closes: https://lore.kernel.org/lkml/Z_Tlc6Qs-tYpxWYb@linaro.org/ Reported-by: Stephan Gerhold Signed-off-by: Rafael J. Wysocki Reviewed-by: Christian Loehle Link: https://patch.msgid.link/3010358.e9J7NaK4W3@rjwysocki.net Signed-off-by: Sasha Levin --- kernel/sched/cpufreq_schedutil.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index d8b9e1d25200f..c1307bbdc291b 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -90,7 +90,7 @@ static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 time) if (unlikely(sg_policy->limits_changed)) { sg_policy->limits_changed = false; - sg_policy->need_freq_update = cpufreq_driver_test_flags(CPUFREQ_NEED_UPDATE_LIMITS); + sg_policy->need_freq_update = true; return true; } @@ -102,10 +102,22 @@ static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 time) static bool sugov_update_next_freq(struct sugov_policy *sg_policy, u64 time, unsigned int next_freq) { - if (sg_policy->need_freq_update) + if (sg_policy->need_freq_update) { sg_policy->need_freq_update = false; - else if (sg_policy->next_freq == next_freq) + /* + * The policy limits have changed, but if the return value of + * cpufreq_driver_resolve_freq() after applying the new limits + * is still equal to the previously selected frequency, the + * driver callback need not be invoked unless the driver + * specifically wants that to happen on every update of the + * policy limits. + */ + if (sg_policy->next_freq == next_freq && + !cpufreq_driver_test_flags(CPUFREQ_NEED_UPDATE_LIMITS)) + return false; + } else if (sg_policy->next_freq == next_freq) { return false; + } sg_policy->next_freq = next_freq; sg_policy->last_freq_update_time = time; -- 2.39.5