[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] xen/cpufreq: Reset policy after enabling/disabling turbo status
- To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Thu, 11 Nov 2021 12:06:40 +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=Lf72snFv18W+agWakeUdA65Tpb3lkqN7PO1TtJF4EYw=; b=JOkCwmpvL8nyx/edydr7ilC1JezDoFuCRpPtgdtTy3ZK7jTsHNGDJGEyVxdDpa7K57H2Q8cTdIbAAcA1lynUaPgO7r2dOJXmw3LR8L9tULdn36nMOtwMGWG5hpi8xJH1pIFHIoEx3+hhCRsKrhNpCEi4W5/toRk9LB9XQq5TS5KmX2/WuH8Yli59Iclm2tDx1oicvdaY3kw207LjfHpH4Q0dOTg2p/Ad8qTABMmMq+ML9Zrrht+dTLKpxyWC7UD60nJPXlArCOtxw19ry1tFuYIcat3EeFFKHSxrN6volvXtgeZJxnOpOXKtVTDu6FuE1IIaI7P3e9fi8I96ZtWb/g==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FKfl8SJVfhNshRskJZvrXwk2Ubpc7Sf9SsnGA/fHNDuYpsqjSoR2eBMYRkitdthiFbr0usgb9uO9Fn52a4HyqqI8AiU2diIkUrd73BCjrVY1oqtQy2pFyjMH4fYamwx/gpIjo/x+txIvAIbsvq9yDGJTYHbLWzXAk2bnvQOJBadff45kRkwR+D7XmDWRw2yWfnFkIeUX9Bkp2oftligvzXpDfHp1wcak42GsEwGUaTEDAHxgLLC34qYRT90sm+MnecTA5y9XJ45Egm65P1LwuiP+XJz6trWI5MnLu+1bje3Fg+C849CCFcjLgeqmvTFBe/HUqrgKRa7z6bs+V/FjEQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Jane Malalane <jane.malalane@xxxxxxxxxx>
- Delivery-date: Thu, 11 Nov 2021 11:07:01 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 10.11.2021 13:39, Roger Pau Monné wrote:
> On Wed, Nov 10, 2021 at 09:19:35AM +0000, Jane Malalane wrote:
>> --- 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);
>
> Do you need to revert the policy->turbo value to the previous one if
> the call to __cpufreq_governor returns an error? (much like it's done
> for the .update call above).
I guess this can be viewed either way: Keeping the value would allow
a later successful invocation of the .target() hook to observe the
intended value. Obviously then it's questionable whether returning an
error in that case isn't going to be misleading - failure of the
policy update would then rather need to be indicated by some
"deferred" indicator (which we don't have). Taking into account the
behavior prior to this patch I wonder whether it's an option to
simply ignore an error from __cpufreq_governor() here.
Jan
|
