Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp103939pxx; Tue, 27 Oct 2020 22:58:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwtkNyoSoL3AWCj0JzVCjGXxpdmj4XEJGiV0w49lhdZv7CHwUWo5Z0UWCcDYGaZyDeFeXeJ X-Received: by 2002:a05:6402:1ad9:: with SMTP id ba25mr6179974edb.120.1603864687530; Tue, 27 Oct 2020 22:58:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603864687; cv=none; d=google.com; s=arc-20160816; b=PRk4ns7RBS8LoHtITY8bVZIWRC/NO/ndEX55Tkp5dp5tiFp1oI5iS+ndlsx16GqSiK dthi0JEQHgP7LR2DivDOhLqwagaKF4G6vCl9UGdKgnFTQcIUUJUKHEhKTDKXT61fvsaS K7fd1mJfjh2COy58vlnP6HheuISqqGoC1zOGV9NSCc7cwHDZahlnUS9ELP0gqjepNAJV FY79ELf1v0UnTu9cUKkOsXUakhqYxRG0/ZATHWh1+/NrbnlkVdU6DKxfRn/M76frHIGE Fij1DCs+0RyyDYLriie/Nl6OGWs6Xr6WLQnKzgapY4dgHNuBiSX4kuztLqUDYzB2yFXO /Kew== 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:date:cc:to:from:subject:message-id :ironport-sdr:ironport-sdr; bh=kk4cLz+Um5kUH3mm/o26A/dZ3obIyGkguYhhp1voC4o=; b=gYhaLAIaIz7kfzx9f0DQBjH4kK/1B+oC/kuThKeh2OEm9mWD1HHV0hVzU2KgIvMFHN 95qTvf9H5abvOZLqOuKoxSqLEOnsBQGYqlwiCFa5bi1QXP5TNamJ3sIFkkInWtmZxg2f oXpj+sDlIJ4CdlF/PbEisokgElZllpN7aKLcLByPRZyNEAT0NbP9iqo5u5YF+JeVmH/F kgCJaQP8SEksTkfZpCX8HB6sg8sytEsJn0L3FS2JYRscxlI/c9IjIZNNEvwMb4HRfzaS G90jPSxv78UjIxPkbX9m4j+RL+x9dqz2x+xP+I3hCOYNLCAJRv3+7N+igaSJZoO/ofiQ 7TaQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ot10si625423ejb.244.2020.10.27.22.57.45; Tue, 27 Oct 2020 22:58:07 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2509269AbgJ0IrI (ORCPT + 99 others); Tue, 27 Oct 2020 04:47:08 -0400 Received: from mga01.intel.com ([192.55.52.88]:49696 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2395489AbgJ0IrH (ORCPT ); Tue, 27 Oct 2020 04:47:07 -0400 IronPort-SDR: AzEJ2m8Q/gXlzkLPlsfi8IR2T66Hfn/vze5I/L2abBytfbkOyzMVOK2HQlQv8Uep5flw+dJNWO T+n8bnJ9Wq8w== X-IronPort-AV: E=McAfee;i="6000,8403,9786"; a="185785440" X-IronPort-AV: E=Sophos;i="5.77,423,1596524400"; d="scan'208";a="185785440" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Oct 2020 01:47:07 -0700 IronPort-SDR: pkB0yZgBu4yrbBvF/VdPfd24RDOD1EXaLC5jcnqqXO/+KplfTJP5kBgA7CuGBvMx435HyxF/GG LFHOthsbjGpw== X-IronPort-AV: E=Sophos;i="5.77,423,1596524400"; d="scan'208";a="525812017" Received: from zzhao15-mobl1.ccr.corp.intel.com ([10.255.30.125]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Oct 2020 01:47:05 -0700 Message-ID: Subject: Re: [PATCH v2 2/4] cpufreq: intel_pstate: Avoid missing HWP max updates in passive mode From: Zhang Rui To: "Rafael J. Wysocki" , Linux PM , Viresh Kumar Cc: LKML , Srinivas Pandruvada Date: Tue, 27 Oct 2020 16:47:02 +0800 In-Reply-To: <3212190.yEXfVNHMLB@kreacher> References: <2183878.gTFULuzKx9@kreacher> <3212190.yEXfVNHMLB@kreacher> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2020-10-23 at 17:35 +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > If the cpufreq policy max limit is changed when intel_pstate operates > in the passive mode with HWP enabled and the "powersave" governor is > used on top of it, the HWP max limit is not updated as appropriate. > > Namely, in the "powersave" governor case, the target P-state > is always equal to the policy min limit, so if the latter does > not change, intel_cpufreq_adjust_hwp() is not invoked to update > the HWP Request MSR due to the "target_pstate != old_pstate" check > in intel_cpufreq_update_pstate(), so the HWP max limit is not > updated as a result. > > Also, if the CPUFREQ_NEED_UPDATE_LIMITS flag is not set for the > driver and the target frequency does not change along with the > policy max limit, the "target_freq == policy->cur" check in > __cpufreq_driver_target() prevents the driver's ->target() callback > from being invoked at all, so the HWP max limit is not updated. > > To prevent that occurring, set the CPUFREQ_NEED_UPDATE_LIMITS flag > in the intel_cpufreq driver structure if HWP is enabled and modify > intel_cpufreq_update_pstate() to do the "target_pstate != old_pstate" > check only in the non-HWP case and let intel_cpufreq_adjust_hwp() > always run in the HWP case (it will update HWP Request only if the > cached value of the register is different from the new one including > the limits, so if neither the target P-state value nor the max limit > changes, the register write will still be avoided). > > Fixes: f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive mode > with HWP enabled") > Reported-by: Zhang Rui > Cc: 5.9+ # 5.9+ > Signed-off-by: Rafael J. Wysocki I have confirmed that the problem is gone with this patch series applied. The HWP register is updated after changing the scaling_max_freq sysfs attribute, with powersave governor. Tested-by: Zhang Rui thanks, rui > --- > > The v2 is just the intel_pstate changes (without the core changes) > and setting > the new flag. > > --- > drivers/cpufreq/intel_pstate.c | 13 ++++++------- > 1 file changed, 6 insertions(+), 7 deletions(-) > > Index: linux-pm/drivers/cpufreq/intel_pstate.c > =================================================================== > --- linux-pm.orig/drivers/cpufreq/intel_pstate.c > +++ linux-pm/drivers/cpufreq/intel_pstate.c > @@ -2550,14 +2550,12 @@ static int intel_cpufreq_update_pstate(s > int old_pstate = cpu->pstate.current_pstate; > > target_pstate = intel_pstate_prepare_request(cpu, > target_pstate); > - if (target_pstate != old_pstate) { > + if (hwp_active) { > + intel_cpufreq_adjust_hwp(cpu, target_pstate, > fast_switch); > + cpu->pstate.current_pstate = target_pstate; > + } else if (target_pstate != old_pstate) { > + intel_cpufreq_adjust_perf_ctl(cpu, target_pstate, > fast_switch); > cpu->pstate.current_pstate = target_pstate; > - if (hwp_active) > - intel_cpufreq_adjust_hwp(cpu, target_pstate, > - fast_switch); > - else > - intel_cpufreq_adjust_perf_ctl(cpu, > target_pstate, > - fast_switch); > } > > intel_cpufreq_trace(cpu, fast_switch ? > INTEL_PSTATE_TRACE_FAST_SWITCH : > @@ -3014,6 +3012,7 @@ static int __init intel_pstate_init(void > hwp_mode_bdw = id->driver_data; > intel_pstate.attr = hwp_cpufreq_attrs; > intel_cpufreq.attr = hwp_cpufreq_attrs; > + intel_cpufreq.flags |= > CPUFREQ_NEED_UPDATE_LIMITS; > if (!default_driver) > default_driver = &intel_pstate; > > > >