From: Kevin Hilman <khilman@ti.com>
To: Jean Pihet <jean.pihet@newoldbits.com>
Cc: Grazvydas Ignotas <notasas@gmail.com>,
linux-omap@vger.kernel.org, Paul Walmsley <paul@pwsan.com>
Subject: Re: PM related performance degradation on OMAP3
Date: Tue, 01 May 2012 10:27:46 -0700 [thread overview]
Message-ID: <87txzzhkvh.fsf@ti.com> (raw)
In-Reply-To: <CAORVsuXX9c+8-uJ1e1U920_jy0MK53jmCu+hXhHaXapHArMeLg@mail.gmail.com> (Jean Pihet's message of "Tue, 1 May 2012 16:10:44 +0200")
Jean Pihet <jean.pihet@newoldbits.com> writes:
> HI Kevin, Grazvydas,
>
> On Tue, Apr 24, 2012 at 4:29 PM, Kevin Hilman <khilman@ti.com> wrote:
>> Jean Pihet <jean.pihet@newoldbits.com> writes:
>>
>>> Hi Grazvydas, Kevin,
>>>
>>> I did some gather some performance measurements and statistics using
>>> custom tracepoints in __omap3_enter_idle.
> I posted the patches for the power domains registers cache, cf.
> http://marc.info/?l=linux-omap&m=133587781712039&w=2.
>
>>> All the details are at
>>> http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#C1_performance_problem:_analysis
> I updated the page with the measurements results with Kevin's patches
> and the registers cache patches.
>
> The results are showing that:
> - the registers cache optimizes the low power mode transitions, but is
> not sufficient to obtain a big gain. A few unused domains are
> transitioning, which causes a big penalty in the idle path.
PER is the one that seems to be causing the most latency.
Can you try do your measurements using hack below which makes sure that
PER isn't any deeper than CORE?
Kevin
>From bb2f67ed93dc83c645080e293d315d383c23c0c6 Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@ti.com>
Date: Mon, 16 Apr 2012 17:53:14 -0700
Subject: [PATCH] cpuidle34xx: per follows core, C1 use _bm
---
arch/arm/mach-omap2/cpuidle34xx.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 374708d..00400ad 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -278,9 +278,11 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
cx = cpuidle_get_statedata(&dev->states_usage[index]);
core_next_state = cx->core_state;
per_next_state = per_saved_state = pwrdm_read_next_pwrst(per_pd);
- if ((per_next_state == PWRDM_POWER_OFF) &&
- (core_next_state > PWRDM_POWER_RET))
- per_next_state = PWRDM_POWER_RET;
+ /* if ((per_next_state == PWRDM_POWER_OFF) && */
+ /* (core_next_state > PWRDM_POWER_RET)) */
+ /* per_next_state = PWRDM_POWER_RET; */
+ if (per_next_state < core_next_state)
+ per_next_state = core_next_state;
/* Are we changing PER target state? */
if (per_next_state != per_saved_state)
@@ -374,7 +376,6 @@ int __init omap3_idle_init(void)
/* C1 . MPU WFI + Core active */
_fill_cstate(drv, 0, "MPU ON + CORE ON");
- (&drv->states[0])->enter = omap3_enter_idle;
drv->safe_state_index = 0;
cx = _fill_cstate_usage(dev, 0);
cx->valid = 1; /* C1 is always valid */
--
1.7.9.2
next prev parent reply other threads:[~2012-05-01 17:27 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-06 22:50 PM related performance degradation on OMAP3 Grazvydas Ignotas
2012-04-09 19:03 ` Kevin Hilman
2012-04-11 0:29 ` Grazvydas Ignotas
2012-04-12 0:19 ` Kevin Hilman
2012-04-13 17:32 ` Grazvydas Ignotas
2012-04-13 19:32 ` Grazvydas Ignotas
2012-04-17 14:30 ` Kevin Hilman
2012-04-17 21:50 ` Grazvydas Ignotas
2012-04-18 0:36 ` Kevin Hilman
2012-04-24 9:50 ` Jean Pihet
2012-04-24 10:38 ` Santosh Shilimkar
2012-04-24 12:21 ` Tero Kristo
2012-04-24 12:50 ` Jean Pihet
2012-04-24 13:04 ` Tero Kristo
2012-04-24 14:29 ` Kevin Hilman
2012-05-01 14:10 ` Jean Pihet
2012-05-01 17:27 ` Kevin Hilman [this message]
2012-05-02 5:59 ` Paul Walmsley
2012-05-02 19:46 ` Jean Pihet
2012-05-07 17:31 ` Kevin Hilman
2012-05-09 11:00 ` Jean Pihet
2012-04-12 23:02 ` Woodruff, Richard
2012-04-11 14:59 ` Gary Thomas
2012-04-11 17:23 ` Grazvydas Ignotas
2012-04-11 18:20 ` Gary Thomas
2012-04-11 19:17 ` Kevin Hilman
2012-04-12 10:44 ` Gary Thomas
2012-04-12 14:14 ` Kevin Hilman
2012-04-12 15:28 ` Gary Thomas
2012-04-12 16:57 ` Kevin Hilman
2012-04-12 17:10 ` Gary Thomas
2012-04-12 18:08 ` Kevin Hilman
2012-04-12 19:05 ` Gary Thomas
2012-04-12 22:03 ` Kevin Hilman
2012-04-13 0:39 ` Gary Thomas
2012-04-13 9:13 ` Felipe Balbi
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=87txzzhkvh.fsf@ti.com \
--to=khilman@ti.com \
--cc=jean.pihet@newoldbits.com \
--cc=linux-omap@vger.kernel.org \
--cc=notasas@gmail.com \
--cc=paul@pwsan.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.