public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Vishwanath Sripathy <vishwanath.bs-l0cyMroinI0@public.gmane.org>
To: Mike Turquette <mturquette-l0cyMroinI0@public.gmane.org>
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org
Subject: RE: [PATCH] OMAP PM: Optimize cpufreq transition latency
Date: Wed, 1 Dec 2010 09:56:48 +0530	[thread overview]
Message-ID: <ec3610408bb3eb61cc3415f0f2f3ace1@mail.gmail.com> (raw)
In-Reply-To: <AANLkTin7QLrwjpwkbrq-5qo+5WH9KmqVmcJh61kbwXYw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

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

  parent reply	other threads:[~2010-12-01  4:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-25 13:38 [PATCH] OMAP PM: Optimize cpufreq transition latency Vishwanath BS
2010-11-30 19:49 ` Turquette, Mike
     [not found]   ` <AANLkTin7QLrwjpwkbrq-5qo+5WH9KmqVmcJh61kbwXYw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-12-01  4:26     ` Vishwanath Sripathy [this message]
2010-12-01 14:28   ` Gopinath, Thara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ec3610408bb3eb61cc3415f0f2f3ace1@mail.gmail.com \
    --to=vishwanath.bs-l0cymroini0@public.gmane.org \
    --cc=linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org \
    --cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mturquette-l0cyMroinI0@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox