On Monday, January 09, 2012, mark gross wrote:

On Sun, Jan 08, 2012 at 11:59:24PM +0100, Rafael J. Wysocki wrote:

quoted

On Friday, January 06, 2012, mark gross wrote:

quoted

On Fri, Jan 06, 2012 at 02:36:20AM +0200, Antti P Miettinen wrote:

quoted

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. There is also
an example module for boosting the frequency upon input events.

I've been testing these changes against Ubuntu 3.2 kernel on a Dell
E6420 with the ACPI cpufreq driver. The patches are against
linux-next/master, compile tested against it.

	--Antti

Alex Frid (1):
  PM QoS: Simplify PM QoS expansion/merge

Antti P Miettinen (5):
  PM QoS: Add CPU frequency min/max as PM QoS params
  cpufreq: Export user_policy min/max
  cpufreq: Preserve sysfs min/max request
  cpufreq: Enforce PM QoS min/max limits
  input: CPU frequency booster

 drivers/cpufreq/cpufreq.c     |   57 +++++++++++++-
 drivers/input/Kconfig         |    9 ++
 drivers/input/Makefile        |    1 +
 drivers/input/input-cfboost.c |  174 +++++++++++++++++++++++++++++++++++++++++
 include/linux/pm_qos.h        |   19 ++++-
 kernel/power/qos.c            |   55 ++++++++++----
 6 files changed, 293 insertions(+), 22 deletions(-)
 create mode 100644 drivers/input/input-cfboost.c

The following is my version of part of this patch set I was tinkering
with.  Its missing the cpufreq notification this change has and doesn't
do anything WRT cfboost.

Would it be ok if we could consolidate our two implementations and
completely separate the cfboost stuff as a separate patch set?

My code below is missing the cpufreq notification logic you have.

Well, I have one substantial problem with this approach.  Namely, our
current PM QoS infrastructure is not suitable for throughput constraints,
because they should be additive, unlike the latency ones.

Namely, if sombody requests throughput X and someone else Y, the resulting
combined throughput should be X+Y rather than max(X, Y).

That can be done easy enough.  However; in practice I'm not convinced
doing and additive aggregation of the requested QoS would be any better
than just taking the max.

Well, I'd say it's necessary for correctness, perhaps not for the CPU, but in
general.  If Y is the max, then the subsystem that requested X may easily
starve whoever requested the Y by using all of the bandwidth it asked for.

But, we can give it a try.

Good. :-)

Thanks,
Rafael