I think the original code had checks in 3 places but as you say it might have changed in linux-omap. I feel the right way to do this is to add a latency (using pm_qos) so that the CPU idle driver doesn't even attempt deeper idle states. Ideally we should use PM_QOS_NETWORK_LATENCY but the menu governor seems to check only PM_QOS_CPU_DMA_LATENCY class. I am not sure why menu governor does not check the other classes of latency. But for now I think if we add to PM_QOS_CPU_DMA_LATENCY when we detect some network activity and remove latency req after a while of network inactivity.
Thanks, -Romit ________________________________________ From: [email protected] [[email protected]] On Behalf Of Premi, Sanjeev [[email protected]] Sent: Saturday, February 28, 2009 11:22 PM To: [email protected] Subject: omap3 cpuidle interrupt latency I have noticed large interrupt latency when the cpuidle is enabled. e.g. response time for ping goes from avg 10-20ms to 800-1000ms. (I am at HEAD of the 'pm' branch) The IRQs and FIQs are disabled at the beginning of the function omap3_enter_idle() but WFI is executed much later in _omap_sram_idle(). In between, there is only one check for pending IRQs - omap_irq_pending() If any interrupt occurs beyond this point is it considered by the WFI? To reduce this latency, I am planning to do either/both of thse: - Add more checks for pending IRQs - Reduce the time for which the IRQs and FIQs are disabled Benefits will depend upon the behavior of WFI. Best regards, Sanjeev -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
