On Thu, Oct 25, 2007 at 08:54:28PM +0200, Dominik Brodowski wrote:
> Hi Mark,
>
> On Wed, Oct 24, 2007 at 02:21:50PM -0700, Mark Gross wrote:
> > > On Thu, Oct 04, 2007 at 02:51:39PM -0700, Mark Gross wrote:
> > > What about cpu_throughput{_min,_max}, as being something considered to be
> > > proportional to the CPU frequency? This way, the cpufreq policy notifiers
> > > might be able to utilize the pm_qos infrastructure; but maybe even also the
> > > userspace interface (at least the min freq/max freq one)... Haven't thought
> > > this through, but maybe you (or someone else) has.
> >
> > I've only thought it though enough to choose to avoid cpufreq
> > interactions.
> >
> > Sadly core frequency is not proportional to throughput on X86
> > processors. I don't know how one would reliably quantify cpu throughput
> > in this context, other than defining latencies.
>
> Well it's not exactly throughput, but the CPU frequency surely has an
> influence on it and also affects the quality of the service provided...
This is true. I just worry going down this path would be a rat-hole.
FWIW I suppose one could use define bogo-mips as the throughput
parameter and use that as away for a CPUFREQ driver to use a way to
constrain the throttling. This way if an application that knows it
needs higher throughputs and can't deal with the latencies of the
governor changing core voltage and frequencies, it could register itself
to PM_QOS.
In theory this could open a window to more aggressive governor policies
for saving power. I can see how that could work well for specific
workloads but not so much for desktop / general purpose workloads..
>
> > I could see something like this to prevent cpufreq throttling at bad
> > times, but how common of an issue is this any more?
>
> Hopefully none :) I was just wondering whether this generalization would
> make sense in the big scheme of things (i.e. grand plan of unified power
> management)...
>
Maybe you are right.
Is there interest in anyone creating a new, or enhanced CPUFREQ governor
that takes advantage of a PM_QOS bogo-mips throughput parameter to limit
how low of a P-state to drop into?
If so I'd be happy to work with you to see what we can accomplish.
--mgross
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
