From: Jean Pihet <jean.pihet@newoldbits.com>
To: Kevin Hilman <khilman@ti.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: Wed, 9 May 2012 13:00:15 +0200 [thread overview]
Message-ID: <CAORVsuWcSp9rY1oUe3copaWVYy2tz8QKMuFQXWeTVkge7GYFQA@mail.gmail.com> (raw)
In-Reply-To: <878vh36gpl.fsf@ti.com>
Hi Kevin,
On Mon, May 7, 2012 at 7:31 PM, Kevin Hilman <khilman@ti.com> wrote:
> Jean Pihet <jean.pihet@newoldbits.com> writes:
>
>> On Tue, May 1, 2012 at 7:27 PM, Kevin Hilman <khilman@ti.com> wrote:
>>> 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?
>>
>> Indeed your patch brings significant improvements, cf. wiki page at
>> http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#C1_performance_problem:_analysis
>> for detailed information.
>> Here below is the reworked patch, more suited for inclusion in mainline [1]
>>
>> I have another optimisation -in proof of concept state- that brings
>> another significant improvement. It is about allowing/disabling idle
>> for only 1 clkdm in a pwrdm and not iterate through all the clkdms.
>> This still needs some rework though. Cf. patch [2]
>
> That should work since disabling idle for any clkdm will have the same
> effect. Can you send this as a separate patch with a descriptive
> changelog.
I just sent 2 patches which optimize the C1 state latency:
. [PATCH 1/2] ARM: OMAP3: PM: cpuidle: optimize the PER latency in C1 state
. [PATCH 2/2] ARM: OMAP3: PM: cpuidle: optimize the clkdm idle
latency in C1 state
Note: those patches apply on top of your pre/post_transition
optimization patches.
The performance results are close to the !PM case (No IDLE, no
omap_sram_idle, all pwrdms to ON), i.e. 3.1MB/s on Beagleboard.
The wiki page update comes asap.
Regards,
Jean
>
> Kevin
>
>
>> Patches [1] and [2] on top of the registers cache and the
>> optimisations in pre/post_transition bring the performance close to
>> the performance for the non cpuidle case (3.0MB/s compared to 3.1MB/s
>> on Beagleboard).
>>
>> What do you think?
>>
>> Regards,
>> Jean
>>
>> ---
>> [1]
>> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
>> b/arch/arm/mach-omap2/cpuidle34xx.c
>> index e406d7b..572b605 100644
>> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
>> @@ -279,32 +279,36 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
>> int ret;
>>
>> /*
>> - * Prevent idle completely if CAM is active.
>> + * Use only C1 if CAM is active.
>> * CAM does not have wakeup capability in OMAP3.
>> */
>> - if (pwrdm_read_func_pwrst(cam_pd) == PWRDM_FUNC_PWRST_ON) {
>> + if (pwrdm_read_func_pwrst(cam_pd) == PWRDM_FUNC_PWRST_ON)
>> new_state_idx = drv->safe_state_index;
>> - goto select_state;
>> - }
>> -
>> - new_state_idx = next_valid_state(dev, drv, index);
>> + else
>> + new_state_idx = next_valid_state(dev, drv, index);
>>
>> - /*
>> - * Prevent PER off if CORE is not in retention or off as this
>> - * would disable PER wakeups completely.
>> - */
>> + /* Program PER state */
>> cx = cpuidle_get_statedata(&dev->states_usage[new_state_idx]);
>> core_next_state = cx->core_state;
>> - per_next_state = per_saved_state = pwrdm_read_next_func_pwrst(per_pd);
>> - if ((per_next_state == PWRDM_FUNC_PWRST_OFF) &&
>> - (core_next_state > PWRDM_FUNC_PWRST_CSWR))
>> - per_next_state = PWRDM_FUNC_PWRST_CSWR;
>> + if (new_state_idx == 0) {
>> + /* In C1 do not allow PER state lower than CORE state */
>> + per_next_state = core_next_state;
>> + } else {
>> + /*
>> + * Prevent PER off if CORE is not in RETention or OFF as this
>> + * would disable PER wakeups completely.
>> + */
>> + per_next_state = per_saved_state =
>> + pwrdm_read_next_func_pwrst(per_pd);
>> + if ((per_next_state == PWRDM_FUNC_PWRST_OFF) &&
>> + (core_next_state > PWRDM_FUNC_PWRST_CSWR))
>> + per_next_state = PWRDM_FUNC_PWRST_CSWR;
>> + }
>>
>> /* Are we changing PER target state? */
>> if (per_next_state != per_saved_state)
>> omap_set_pwrdm_state(per_pd, per_next_state);
>>
>> -select_state:
>> ret = omap3_enter_idle(dev, drv, new_state_idx);
>>
>> /* Restore original PER state if it was modified */
>> @@ -390,7 +394,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 */
>>
>> [2]
>> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
>> b/arch/arm/mach-omap2/cpuidle34xx.c
>> index e406d7b..6aa3c75 100644
>> --- a/arch/arm/mach-omap2/cpuidle34xx.c
>> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
>> @@ -118,8 +118,10 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
>>
>> /* Deny idle for C1 */
>> if (index == 0) {
>> - pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
>> - pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
>> + //pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
>> + clkdm_deny_idle(mpu_pd->pwrdm_clkdms[0]);
>> + //pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
>> + clkdm_deny_idle(core_pd->pwrdm_clkdms[0]);
>> }
>>
>> /*
>> @@ -141,8 +143,10 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
>>
>> /* Re-allow idle for C1 */
>> if (index == 0) {
>> - pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
>> - pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
>> + //pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
>> + clkdm_allow_idle(mpu_pd->pwrdm_clkdms[0]);
>> + //pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
>> + clkdm_allow_idle(core_pd->pwrdm_clkdms[0]);
>> }
>>
>> return_sleep_time:
>>
>>>
>>> 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
>>>
>>> --
>>> 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
--
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
next prev parent reply other threads:[~2012-05-09 11:00 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
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 [this message]
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=CAORVsuWcSp9rY1oUe3copaWVYy2tz8QKMuFQXWeTVkge7GYFQA@mail.gmail.com \
--to=jean.pihet@newoldbits.com \
--cc=khilman@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).