Re: [PATCH] cpufreq: Add user_min/max_freq

From: Matthias Kaehlcke <mka@chromium.org>
To: Leonard Crestez <leonard.crestez@nxp.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	Saravana Kannan <saravanak@google.com>,
	linux-pm@vger.kernel.org, Viresh Kumar <viresh.kumar@linaro.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Chanwoo Choi <cw00.choi@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	MyungJoo Ham <myungjoo.ham@samsung.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] cpufreq: Add user_min/max_freq
Date: Wed, 30 Oct 2019 12:18:19 -0700	[thread overview]
Message-ID: <20191030191819.GB27773@google.com> (raw)
In-Reply-To: <c222deda79ad334ff4edcbd49ddda248685c4ee1.1572395990.git.leonard.crestez@nxp.com>

On Wed, Oct 30, 2019 at 02:41:49AM +0200, Leonard Crestez wrote:
> Current values in scaling_min_freq and scaling_max freq can change on
> the fly due to event such as thermal monitoring. This behavior is
> confusing for userspace and because once an userspace limit is written
> to scaling_min/max_freq it is not possible to read it back.

Yes, this is indeed confusing.

> Introduce two new user_min/max_freq files which only contain the limits
> imposed by userspace, without any aggregation.
> 
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> 
> ---
> This was motivated by these discussions:
> 
> * https://patchwork.kernel.org/patch/11078475/#22805379
> * https://patchwork.kernel.org/patch/11171817/#22917099
> 
> Those threads are about devfreq but same issue applies to cpufreq as
> well. Let me know if this solution seems reasonable?
> 
> An alternative would be to make scaling_min/max_freq always read back
> the configured value and introduce new effective_min/max_freq files for
> the aggregate values. That might break existing users (though I'm not
> familiar with any).

It seems there isn't really a perfect solution :(

This change creates a set of new, consistent attributes, but since we
can't make the current min/max attributes read-only userspace will keep
using them forever.

It's somewhat doubtful that userspace can do anything useful with the
current min/max values, since they might change just after being read.
Anything besides monitoring the limits (approximately) would be inherently
broken.

Having min/max return the configured value would be the expected behavior
(IMO), but obviously I also don't know for sure if there are userspace
components relying on the current behavior.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel