Currently cpufreq transition latency value does not really reflect the actual OMAP OPP transition delay. This patch has the actual latency value. I did profile the DVFS latency on OMAP3430, OMAP3630 and OMAP4 for worstcase(MPU and Core together) and found that in none of these platforms, transiton value goes beyong 10ms. Added a buffer of 20ms to avoid too frequent ondemand timer expiry. With this change, performance of ondemand governor is improved when tested using cpufreqbench tool. Without this patch, cpufreq-bench reported ondemand performance as 40% of performance governor, and with this patch it's around 70% (using below procedure).
cpufreq-bench: http://lwn.net/Articles/339862/ http://ftp.riken.go.jp/archives/Linux/suse/people/ckornacker/cpufreq-bench/
Command used for performance testing: cpufreq-bench -l 50000 -s 100000 -x 50000 -y 100000 -g ondemand -r 5 -n 5 -v
Signed-off-by: Vishwanath BS vishwanath.bs@ti.com --- arch/arm/plat-omap/cpu-omap.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) mode change 100644 => 100755 arch/arm/plat-omap/cpu-omap.c
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c old mode 100644 new mode 100755 index c47faf8..d3fc423 --- a/arch/arm/plat-omap/cpu-omap.c +++ b/arch/arm/plat-omap/cpu-omap.c @@ -158,8 +158,8 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy) policy->max = policy->cpuinfo.max_freq; policy->cur = omap_getspeed(0);
- /* FIXME: what's the actual transition time? */ - policy->cpuinfo.transition_latency = 300 * 1000; + /* Program the actual transition time for worstcase */ + policy->cpuinfo.transition_latency = 30 * 1000;
return 0; }
On Thu, Nov 25, 2010 at 7:38 AM, Vishwanath BS vishwanath.bs@ti.com wrote:
Currently cpufreq transition latency value does not really reflect the actual OMAP OPP transition delay. This patch has the actual latency value. I did profile the DVFS latency on OMAP3430, OMAP3630 and OMAP4 for worstcase(MPU and Core together) and found that in none of these platforms, transiton value goes beyong 10ms. Added a buffer of 20ms to avoid too frequent ondemand timer expiry. With this change, performance of ondemand governor is improved when tested using cpufreqbench tool. Without this patch, cpufreq-bench reported ondemand performance as 40% of performance governor, and with this patch it's around 70% (using below procedure).
cpufreq-bench: http://lwn.net/Articles/339862/ http://ftp.riken.go.jp/archives/Linux/suse/people/ckornacker/cpufreq-bench/
Command used for performance testing: cpufreq-bench -l 50000 -s 100000 -x 50000 -y 100000 -g ondemand -r 5 -n 5 -v
Signed-off-by: Vishwanath BS vishwanath.bs@ti.com
arch/arm/plat-omap/cpu-omap.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) mode change 100644 => 100755 arch/arm/plat-omap/cpu-omap.c
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c old mode 100644 new mode 100755 index c47faf8..d3fc423 --- a/arch/arm/plat-omap/cpu-omap.c +++ b/arch/arm/plat-omap/cpu-omap.c @@ -158,8 +158,8 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy) policy->max = policy->cpuinfo.max_freq; policy->cur = omap_getspeed(0);
- /* FIXME: what's the actual transition time? */
- policy->cpuinfo.transition_latency = 300 * 1000;
- /* Program the actual transition time for worstcase */
- policy->cpuinfo.transition_latency = 30 * 1000;
Vishwa,
This is a frequent periodic timer. Does a smaller value have any affect on CPUidle wakeups?
Thanks, Mike
return 0; } -- 1.7.0.4
-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Mike,
-----Original Message----- From: Turquette, Mike [mailto:mturquette@ti.com] Sent: Wednesday, December 01, 2010 1:20 AM To: Vishwanath BS Cc: linux-omap@vger.kernel.org; linaro-dev@lists.linaro.org Subject: Re: [PATCH] OMAP PM: Optimize cpufreq transition latency
On Thu, Nov 25, 2010 at 7:38 AM, Vishwanath BS vishwanath.bs@ti.com wrote:
Currently cpufreq transition latency value does not really reflect the
actual
OMAP OPP transition delay. This patch has the actual latency value. I did profile the DVFS latency on OMAP3430, OMAP3630 and OMAP4
for worstcase(MPU and Core together) and found that in none of these platforms, transiton value
goes beyong 10ms. Added a buffer of 20ms to avoid too frequent
ondemand timer
expiry. With this change, performance of ondemand governor is improved
when tested
using cpufreqbench tool. Without this patch, cpufreq-bench reported
ondemand
performance as 40% of performance governor, and with this patch it's
around 70%
(using below procedure).
cpufreq-bench: http://lwn.net/Articles/339862/ http://ftp.riken.go.jp/archives/Linux/suse/people/ckornacker/cpufreq-
bench/
Command used for performance testing: cpufreq-bench -l 50000 -s 100000 -x 50000 -y 100000 -g ondemand -
r 5 -n 5 -v
Signed-off-by: Vishwanath BS vishwanath.bs@ti.com
arch/arm/plat-omap/cpu-omap.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) mode change 100644 => 100755 arch/arm/plat-omap/cpu-omap.c
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-
omap/cpu-omap.c
old mode 100644 new mode 100755 index c47faf8..d3fc423 --- a/arch/arm/plat-omap/cpu-omap.c +++ b/arch/arm/plat-omap/cpu-omap.c @@ -158,8 +158,8 @@ static int __init omap_cpu_init(struct
cpufreq_policy *policy)
policy->max = policy->cpuinfo.max_freq; policy->cur = omap_getspeed(0);
- /* FIXME: what's the actual transition time? */
- policy->cpuinfo.transition_latency = 300 * 1000;
- /* Program the actual transition time for worstcase */
- policy->cpuinfo.transition_latency = 30 * 1000;
Vishwa,
This is a frequent periodic timer. Does a smaller value have any affect on CPUidle wakeups?
I do not think so since this is a deferrable timer which should not interrupt CPUIdle.
Vishwa
Thanks, Mike
return 0; } -- 1.7.0.4
-- To unsubscribe from this list: send the line "unsubscribe linux-omap"
in
the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----Original Message----- From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- owner@vger.kernel.org] On Behalf Of Turquette, Mike Sent: Wednesday, December 01, 2010 1:20 AM To: Sripathy, Vishwanath Cc: linux-omap@vger.kernel.org; linaro-dev@lists.linaro.org Subject: Re: [PATCH] OMAP PM: Optimize cpufreq transition latency
On Thu, Nov 25, 2010 at 7:38 AM, Vishwanath BS vishwanath.bs@ti.com wrote:
Currently cpufreq transition latency value does not really reflect the
actual
OMAP OPP transition delay. This patch has the actual latency value. I did profile the DVFS latency on OMAP3430, OMAP3630 and OMAP4 for
worstcase(MPU and Core together) and found that in none of these platforms, transiton value
goes beyong 10ms. Added a buffer of 20ms to avoid too frequent ondemand
timer
expiry. With this change, performance of ondemand governor is improved when tested using cpufreqbench tool. Without this patch, cpufreq-bench reported
ondemand
performance as 40% of performance governor, and with this patch it's around
70%
(using below procedure).
cpufreq-bench: http://lwn.net/Articles/339862/ http://ftp.riken.go.jp/archives/Linux/suse/people/ckornacker/cpufreq-bench/
Command used for performance testing: cpufreq-bench -l 50000 -s 100000 -x 50000 -y 100000 -g ondemand -r 5 -n 5 -
v
Signed-off-by: Vishwanath BS vishwanath.bs@ti.com
arch/arm/plat-omap/cpu-omap.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) mode change 100644 => 100755 arch/arm/plat-omap/cpu-omap.c
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c old mode 100644 new mode 100755 index c47faf8..d3fc423 --- a/arch/arm/plat-omap/cpu-omap.c +++ b/arch/arm/plat-omap/cpu-omap.c @@ -158,8 +158,8 @@ static int __init omap_cpu_init(struct cpufreq_policy
*policy)
policy->max = policy->cpuinfo.max_freq; policy->cur = omap_getspeed(0);
- /* FIXME: what's the actual transition time? */
- policy->cpuinfo.transition_latency = 300 * 1000;
- /* Program the actual transition time for worstcase */
- policy->cpuinfo.transition_latency = 30 * 1000;
Vishwa,
This is a frequent periodic timer. Does a smaller value have any affect on CPUidle wakeups?
I thought this is a deferred timer and so should not affect the cpuidle thread at all.
Regards Thara
-
Gopinath, Thara -
Turquette, Mike -
Vishwanath BS -
Vishwanath Sripathy