Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp346593pxx; Thu, 29 Oct 2020 04:14:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxXvx8s9KA+4nQpyfAbz4e+6uy16k8LrCBNmKMggPd1dRB2PSAOqPpy7F1Ud6qPF60wkTGl X-Received: by 2002:a17:906:364d:: with SMTP id r13mr3322744ejb.521.1603970067276; Thu, 29 Oct 2020 04:14:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603970067; cv=none; d=google.com; s=arc-20160816; b=yeU4YmAxQ+0rZ8cAKP8LHaBPUpnedRtVvs+wyFg3OU4NP+2iZYyqw3Tr3AFfefi6Co SDx1lwvx4WQX0AIlqMJV9m0dQXl6YiVdfAEAW36niCKENyHWTlPo6wjuLbQCBuem/jL9 jWq9E1DMpa1OOr4m5rBKeDHWq6oJEUR5dU5E1CkUuvWGWFH5VDaODZw0oEHR9B8fkfLG 7pDLqB+VYIWb2RK8zEhUFxo/CPGNcpH1EfkLMc1eW8KlAgim8oWDho9h0Oy5OHjNWafl y0VAbnVHJGQMjab3byi+g2nk7RuaOmmcS5axR1IHdwGo2IYWg5eLRHafnCjtflCOY5NV 2jXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=cKa2wfv4qe0czMMHkbvhhAyFTe9koUyjIk+IQNyGJgc=; b=LcyQ21/uecpYwJZxd1c2pXB1ymbV/lIVD5DgIrKsMyZf93QtkwFYQFuh5BfDF2JJkK LlGHyKFpjT6HZFJb/RAf8dhdFSawPQ24LOdR9RWg7mhM66CfuwGPSiuu2O2nWTfPfjOr x99chWtiB0NJIcw5ulXMy7XPfjWOYc/YP5j9wCwvWXm1zO68ZuXrXHixHUV64KyfmqpP sfd7ovb1C41nt+aqZx3wZyKCHfoRsDcOmtDF1l17s78rDO5am5j5KpIstGYDl7BQLhlM ULs1SI4MTXECkt7uze3kR8Nf1xRpgUhNcCK11pGMwp37YAiLfKYuuLBGPKwtgl53sYF3 329w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h13si1652179edr.541.2020.10.29.04.14.04; Thu, 29 Oct 2020 04:14:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727205AbgJ2LMt (ORCPT + 99 others); Thu, 29 Oct 2020 07:12:49 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:41710 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726789AbgJ2LMt (ORCPT ); Thu, 29 Oct 2020 07:12:49 -0400 Received: from 89-64-89-121.dynamic.chello.pl (89.64.89.121) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.491) id 1a55d32a351296d0; Thu, 29 Oct 2020 12:12:47 +0100 From: "Rafael J. Wysocki" To: Linux PM , Viresh Kumar Cc: LKML , Srinivas Pandruvada , Zhang Rui Subject: [PATCH v2.2 4/4] cpufreq: schedutil: Always call driver if CPUFREQ_NEED_UPDATE_LIMITS is set Date: Thu, 29 Oct 2020 12:12:46 +0100 Message-ID: <4720046.CcxZZ2xs9j@kreacher> In-Reply-To: <1905098.zDJocX6404@kreacher> References: <2183878.gTFULuzKx9@kreacher> <1905098.zDJocX6404@kreacher> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Rafael J. Wysocki Because sugov_update_next_freq() may skip a frequency update even if the need_freq_update flag has been set for the policy at hand, policy limits updates may not take effect as expected. For example, if the intel_pstate driver operates in the passive mode with HWP enabled, it needs to update the HWP min and max limits when the policy min and max limits change, respectively, but that may not happen if the target frequency does not change along with the limit at hand. In particular, if the policy min is changed first, causing the target frequency to be adjusted to it, and the policy max limit is changed later to the same value, the HWP max limit will not be updated to follow it as expected, because the target frequency is still equal to the policy min limit and it will not change until that limit is updated. To address this issue, modify get_next_freq() to let the driver callback run if the CPUFREQ_NEED_UPDATE_LIMITS cpufreq driver flag is set regardless of whether or not the new frequency to set is equal to the previous one. Fixes: f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive mode with HWP enabled") Reported-by: Zhang Rui Tested-by: Zhang Rui Cc: 5.9+ # 5.9+ Signed-off-by: Rafael J. Wysocki --- v2.1 -> v2.2: * Instead of updating need_freq_update if CPUFREQ_NEED_UPDATE_LIMITS is set in get_next_freq() and checking it again in sugov_update_next_freq(), check CPUFREQ_NEED_UPDATE_LIMITS directly in sugov_update_next_freq(). * Update the subject. v2 -> v2.1: * Fix typo in the subject. * Make get_next_freq() and sugov_update_next_freq() ignore the sg_policy->next_freq == next_freq case when CPUFREQ_NEED_UPDATE_LIMITS is set for the driver. * Add Tested-by from Rui (this version lets the driver callback run more often than the v2, so the behavior in the Rui's case doesn't change). --- kernel/sched/cpufreq_schedutil.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) Index: linux-pm/kernel/sched/cpufreq_schedutil.c =================================================================== --- linux-pm.orig/kernel/sched/cpufreq_schedutil.c +++ linux-pm/kernel/sched/cpufreq_schedutil.c @@ -102,7 +102,8 @@ static bool sugov_should_update_freq(str static bool sugov_update_next_freq(struct sugov_policy *sg_policy, u64 time, unsigned int next_freq) { - if (sg_policy->next_freq == next_freq) + if (sg_policy->next_freq == next_freq && + !cpufreq_driver_test_flags(CPUFREQ_NEED_UPDATE_LIMITS)) return false; sg_policy->next_freq = next_freq; @@ -161,7 +162,8 @@ static unsigned int get_next_freq(struct freq = map_util_freq(util, freq, max); - if (freq == sg_policy->cached_raw_freq && !sg_policy->need_freq_update) + if (freq == sg_policy->cached_raw_freq && !sg_policy->need_freq_update && + !cpufreq_driver_test_flags(CPUFREQ_NEED_UPDATE_LIMITS)) return sg_policy->next_freq; sg_policy->need_freq_update = false;