[PATCH] OMAP PM: Optimize cpufreq transition latency

[PATCH] OMAP PM: Optimize cpufreq transition latency

[Vishwanath BS]

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;
 }
-- 
1.7.0.4

Re: [PATCH] OMAP PM: Optimize cpufreq transition latency

[Turquette, Mike]

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
>
--
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

RE: [PATCH] OMAP PM: Optimize cpufreq transition latency

[Vishwanath Sripathy]

Mike,

> -----Original Message-----
> From: Turquette, Mike [mailto:mturquette-l0cyMroinI0@public.gmane.org]
> Sent: Wednesday, December 01, 2010 1:20 AM
> To: Vishwanath BS
> Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org
> Subject: Re: [PATCH] OMAP PM: Optimize cpufreq transition latency
>
> On Thu, Nov 25, 2010 at 7:38 AM, Vishwanath BS
> <vishwanath.bs-l0cyMroinI0@public.gmane.org> 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-l0cyMroinI0@public.gmane.org>
> > ---
> >  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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >

RE: [PATCH] OMAP PM: Optimize cpufreq transition latency

[Gopinath, Thara]

>>-----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
--
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