Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet.
036 420 040 R.C.S Antibes. Capital de EUR 753.920
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, October 30, 2009 12:33 AM
To: Chikkature Rajashekar, Madhusudhan
Cc: Turquette, Mike; Dasgupta, Romit; Cousson, Benoit; 'Paul Walmsley';
linux-omap@vger.kernel.org; Titiano, Patrick
Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource
framework functions
Madhusudhan madhu...@ti.com writes:
-Original Message-
From: Mike Turquette [mailto:mturque...@ti.com]
Sent: Thursday, October 29, 2009 4:38 PM
To: Kevin Hilman
Cc: Dasgupta, Romit; Cousson, Benoit; Chikkature Rajashekar,
Madhusudhan;
'Paul Walmsley'; linux-omap@vger.kernel.org; Titiano, Patrick
Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource
framework functions
Kevin Hilman wrote:
Dasgupta, Romit ro...@ti.com writes:
Hello Benoit,
One comment below:
In fact, this is Mike who started that analysis. We discussed that
internally and
our point is that if the CPUFreq ondemand or conservative heuristic
is
not able
to increase quickly enough the CPU need to handle correctly the UI,
we
have
to somehow improve or modify the governor in order to provide it a
extra
information in term of constraint maybe in order to increase
immediately the
frequency.
The information as you mention needs to be supplied by the
driver. The governor would then act on behalf of the driver! This
begs for a new governor API or a signature change to an existing
governor API.
This should not be done in the low level omap_pm code; this is not
the right level to do that. The issue is in the ondemand and must
be fixed there.
At the end of the day it would still be the driver making the
decision!
No. The drivers can give hints about their requirements, but the
drivers don't make decisions that are system wide. The govenor acts
on behalf of the entire system based on multiple inputs, not any one
driver.
Benoit's point (and I agree with) is that this is a *system wide*
problem that needs a *system wide* solution. I agree that tweaked or
new governor is the right approach to solving this for the long term,
An assumption in this thread is that ondemand/conservative can't scale
fast enough, but that is not true. The Android UI sluggishness
mentioned by Benoit was solved by lowering the cpufreq
transition_latency time from 10 million ns to 300,000ns. I have not
gotten the exact worst case time that it takes for voltage to scale up
and down from the hardware guys, but through some email exchanges it
was
agreed that this value is safe.
I've pushed the patch that fixed transition_latency to the list.
Please
see thread decrease cpufreq transition latency. This should
hopefully
cure a lot of performance/user experience pain and help us remove
policy
from drivers.
Hi Kevin, Mike,
Let us consider the MMC scenario. Below are the throughput numbers with
different governors.
Performance:
Write: 5.47MB/Sec
Read: 15.3MB/Sec
Ondemand:
Write: 4.2 MB/Sec
Read: 9.8 MB/Sec
Conservative:
Write: 4.9MB/Sec
Read: 12.16MB/Sec
These numbers show that conservative is better than ondemand but the
throughput numbers are still less than performance.
No surprises there.
Instead, if the driver holds the vdd1 opp to opp3 the throughput numbers
were relatively close to performance governor. The logic I am talking
about is that the drivers should be intelligent enough to hold the opp
at
Opp3 only when there is an active transfer. Once the transfer is done
release it back to opp1. Does this make sense?
I think you're missing my point.
What you're trying to do is to allow a driver to make a power
vs. performance policy decision. You're assuming that the user (or
system integrator) will always choose performance over power. What if
the user is willing to accept a slightly slower system if it extends
battery life?
The point I'm trying to make is that these kinds of policy decisions
simply do not belong in drivers.
Kevin
Kevin, this is absolutely correct. I think this is our number one issue in
terms of PM policy.
Today we enterely rely on a single default governor (ondemand) and expect it
to always take the best decision in any circumstances, solely based on the
monitored CPU load. This is quite unrealistic.
I see 4 missing points in our PM SW Framework today:
1/ Hints from low-level drivers to PM policy so that it knows runtime platform
activities and how to react accordingly.
E.g:
- I am DMA-driven, my CPU load is low but I need low latencies (e.g. USB/MMC
transfers, etc ...)
- I am generating huge data transfers, I need high bus speed (e.g. CAMERA)
- I do not support DVFS
- I do not support OFF
