[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <61ea43fce7dd8700d94f12236a86ffec6f76a898.camel@gmail.com>
Date: Tue, 25 Aug 2020 09:20:33 +0300
From: Artem Bityutskiy <dedekind1@...il.com>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Linux PM <linux-pm@...r.kernel.org>
Cc: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
LKML <linux-kernel@...r.kernel.org>,
Doug Smythies <dsmythies@...us.net>
Subject: Re: [PATCH v2 2/5] cpufreq: intel_pstate: Always return last EPP
value from sysfs
On Mon, 2020-08-24 at 19:42 +0200, Rafael J. Wysocki wrote:
> From: "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
>
> Make the energy_performance_preference policy attribute in sysfs
> always return the last EPP value written to it instead of the one
> currently in the HWP Request MSR to avoid possible confusion when
> the performance scaling algorithm is used in the active mode with
> HWP enabled (in which case the EPP is forced to 0 regardless of
> what value it has been set to via sysfs).
Why is this a good idea, I wonder. If there was a prior discussion,
please, point to it.
The general approach to changing settings via sysfs is often like this:
1. Write new value.
2. Read it back and verify that it is the same. Because there is no
better way to verify that the kernel "accepted" the value.
Let's say I write 'balanced' to energy_performance_preference. I read
it back, and it contains 'balanced', so I am happy, I trust the kernel
changed EPP to "balanced".
If the kernel, in fact, uses something else, I want to know about it
and have my script fail. Why caching the value and making my script
_think_ it succeeded is a good idea.
In other words, in my usage scenarios at list, I prefer kernel telling
the true EPP value, not some "cached, but not used" value.
Artem.
Powered by blists - more mailing lists