On Tue, Oct 23, 2007 at 08:03:43PM +0200, Dominik Brodowski wrote:
> Hi Mark,
>
Its good to hear from you. Will you be at the ELC conference in Linz
next week?
> On Thu, Oct 04, 2007 at 02:51:39PM -0700, Mark Gross wrote:
> > Currently we have {cpu_dma_latency, network_latency, network_throughput}
> > as the initial set of pm_qos parameters.
>
> 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.
I could see something like this to prevent cpufreq throttling at bad
times, but how common of an issue is this any more?
Are we wasting watts without such information? Is CPUFREQ still making
some applications behave poorly? Ondemand and cpufreq are fairly mature
now and I don't hear of such issues any more.
--mgross
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
