Re: [PATCH v2 0/8] RFC: CPU frequency min/max as PM QoS params

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Wednesday, January 18, 2012, mark gross wrote:
> On Mon, Jan 16, 2012 at 10:38:57PM +0100, Rafael J. Wysocki wrote:
> > Hi,
> > 
> > On Monday, January 16, 2012, Antti P Miettinen wrote:
> > > [did not reach linux-pm as I sent to wrong address, sorry for
> > > duplicates]
> > > 
> > > The inspiration for this patch series is the N9 CPU frequency boost
> > > upon input events:
> > > 
> > > http://www.spinics.net/lists/cpufreq/msg00667.html
> > > 
> > > and the related changes in git://codeaurora.org/kernel/msm.git tree.
> > > Those patches modify the ondemand cpufreq governor. This patch series
> > > adds minimum and maximum CPU frequency as PM QoS parameters and
> > > modifies the cpufreq core to enforce the PM QoS limits.
> > 
> > If that hasn't been clear enough so far, I'm still not convinced that using
> > PM QoS for that is a good idea.
> > 
> > First off, frequency as a unit of throughput is questionable to say the least,
> > because it isn't portable from one system to another.  Moreover, even on a
> > given system it isn't particularly clear what the exact correspondence
> > between frequency and throughput actually is.
> 
> You are right.  The notion of throughput of a CPU is really hard to
> quantify.  Perhaps not using the term "throughput" would help?

Yes, it would.

> The base issue I see, the Intel platform, is needing is that sometimes
> we need to block the lowest P-states that the ondemand governor goes for
> because those P-states result in media / graphics workloads dropping
> frames.  However; GPU intensive workloads do not stress the CPU so the
> ondemand governor goes for the low p-state.
> 
> I could use some way of constraining the PM-throttling of the
> cpu-freq that can be hit from kernel or user mode.  So the graphics
> driver can dynamically adjust the constraint request on the cpufreq
> subsystem.
> 
> It is problematic that any driver requesting a given frequency request
> is not portable across ISA's or even processor families in the same ISA.
> But, maybe such a driver should use a module parameter to work around
> this lack of portability?

Well, it seems to me that we're trying to add a backdoor to the (apparently
inadequate) governors here.  Arguably, the governors should be able to
make the right decisions on the basis of the information they receive
through their own interfaces.

> > Second, it's not particularly clear what the meaning of the "min" frequency
> > is supposed to be in terms of throughput.
> 
> It should mean "please cpufreq do not put the cpu into a state where its
> clock runs slower than min".  I don't think we should talk about it as
> throughput because thats not what the cpufreq controls.

Perhaps we need a new cpufreq governor that would take use PM QoS internally
to store requests from different sources, but that would work on a per-CPU
basis (not globally) and would provide a new interface for user space?

Rafael