[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] xen/cpufreq: Reset policy after enabling/disabling turbo status


  • To: Jane Malalane <jane.malalane@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 11 Nov 2021 12:00:28 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=N+ZSZcs8LMHeEBhVtCrNtbwSi9N0AxYfGpxUMFiZIn8=; b=Zdw0UigzjAz8t2xruzNBSqifjxbiqomyq/IYUJaOMBHpMCGXBS1sICuaCCH6IlQsHTfiGdkNCDU3JND4zDugcY3cdh7ZvQwxxN74hP+m3FAqkRhJJFK+URb4AYDG+vxejT4sRK0En4U0rz7Xsyfy+HVSXAKK2f1Rzw8FXBn6UBlaHdJWQvGFhES0uF0HazBw+0Jv8rVtwWVzaaVLvdVfYS9pMSFRo83n0KW2swGGPJJUr17c2abo7RQcMFdobFTfwesZjjYpPCqtzgtHndbAbk8VyFIou+5L6XOCmvzj2If5wjSyOgYXrBIZMBjC3Xp0/7cBAiHdU2cQsNYfd38NSA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LomRstbX7Fb4zIJDJXYqs+dZ7rbXklruAUwOuVq2XcRMnjYUcWo9SCpxZCT+NlcxSB/wUasQ8wDRaEjkk8bbwHfa9aEe1M0O3JEHihdVqPUpvMrRDUb96kpZHQozTFyl8LqOLqBA2H6cjH03+KO54xQ9dY8xyEPCUAOLuGU69KY4YVzuu3Z/JRTLUImUhfQ4kqMG3uDBbH4mZmWY+hm0SIEiGaO2v9xOGwHBftaYhhQiLXERDm/OESiqLUDh19CnCnMvySM8ak/YAptz4fMbYa/U9oeT7re5UDG7RWI+zDJ5iJqAXFuEJW/u0N7SO5fgodIHRXZ2cV6qkm3wRBpE8A==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Ian Jackson <iwj@xxxxxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Thu, 11 Nov 2021 11:00:44 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 10.11.2021 10:19, Jane Malalane wrote:
> Before, user would change turbo status but this had no effect: boolean
> was set but policy wasn't reevaluated.  Policy must be reevaluated so
> that CPU frequency is chosen according to the turbo status and the
> current governor.

Aiui this only (or at least mainly) affects the ACPI driver. Powernow
updates CPB via its update hook. I think this wants clarifying.

> Therefore, add __cpufreq_governor() in cpufreq_update_turbo().
> 
> Reported-by: <edvin.torok@xxxxxxxxxx>
> Signed-off-by: <jane.malalane@xxxxxxxxxx>

Nit: These would look better with real names added. Without I'm not
even sure enclosing the email addresses in angle brackets yields
something that's valid.

> Release rationale:
> Not taking this patch means that turbo status is misleading.
> 
> Taking this patch is low-risk as it only uses a function that already
> exists and is already used for setting the chosen scaling governor.
> Essentially, this change is equivalent to running 'xenpm
> en/disable-turbo-mode' and, subsequently, running 'xenpm
> set-scaling-governor <current governor>'.

Otoh things have been this way virtually forever.

> --- a/xen/drivers/cpufreq/utility.c
> +++ b/xen/drivers/cpufreq/utility.c
> @@ -417,10 +417,14 @@ int cpufreq_update_turbo(int cpuid, int new_state)
>      {
>          ret = cpufreq_driver.update(cpuid, policy);
>          if (ret)
> +        {
>              policy->turbo = curr_state;
> +            return ret;
> +        }
>      }
>  
> -    return ret;
> +    /* Reevaluate current CPU policy. */
> +    return __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);

Is this really needed when an .update hook is present? IOW wouldn't
this want to be in an "else" to the preceding if()? Or if not,
would this perhaps be more logically done prior to invoking .update()
(such that the hook would observe the updated policy, in case that's
relevant to what it does)?

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.