Re: PM related performance degradation on OMAP3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 9, 2012 at 10:03 PM, Kevin Hilman <khilman@xxxxxx> wrote:
> Grazvydas Ignotas <notasas@xxxxxxxxx> writes:
>> While SD card performance loss is not that bad (~7%), NAND one is
>> worrying (~39%). I've tried disabling/enabling CONFIG_CPU_IDLE, also
>> cpuidle states over sysfs, it did not have any significant effect. Is
>> there something else to try?
>
> Looks like we might need a PM QoS constraint when there is DMA activity
> in progress.
>
> You can try doing a pm_qos_add_request() for PM_QOS_CPU_DMA_LATENCY when
> DMA transfers are active and I suspect that will help.

I've tried it and it didn't help much. It looks like the only thing it
does is limiting cpuidle c-states, I tried to set qos dma latency to 0
and it made it stay in C1 while transfer was ongoing (I watched
/sys/devices/system/cpu/cpu0/cpuidle/state*/usage), but performance
was still poor.

What I think is going on here is that omap_sram_idle() is taking too
much time because it's overhead is too large. I've added a counter
there and it seems to be called ~530 times per megabyte (DMA operates
in ~2K chunks so it makes sense), that's over 2000 calls per second.
Some quick measurement code shows ~243us spent for setting up in
omap_sram_idle() (before and after omap34xx_do_sram_idle()).

Could we perhaps have a lighter idle function for C1 that doesn't try
to switch all powerdomain states and maybe not enable RAM
self-refresh? As a quick test I've tried this in omap3_enter_idle():

        /* Execute ARM wfi */
        if (index == 0) {
                clkdm_deny_idle(mpu_pd->pwrdm_clkdms[0]);
                cpu_do_idle();
        } else
                omap_sram_idle();

..and it brought performance close to !CONFIG_PM case (cpu_do_idle()
is used as pm_idle on !CONFIG_PM). I don't know what side effects
something like this might have though.

>> Then there is omap3_do_wfi, it seems to be unconditionally putting
>> SDRC on self-refresh, would it make sense to just do wfi in higher
>> power states, like OMAP4 seems to be doing?
>
> Not sure what you're referring to in OMAP4.  There we do WFI in every
> idle state.

What I meant is that OMAP3 idle code always tries to enable RAM
self-refresh (regardless of c-state) before doing wfi while OMAP4 can
do wfi without suspending RAM (although I might be misunderstanding
all that asm code).

-- 
Gražvydas
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux