On Thu, Oct 29, 2009 at 01:09:25PM +0530, Dasgupta, Romit wrote: [Reflowed into 80 columns - you might want to look at your MUA setup.]
> The sampling intervals for the cpufreq governors are quite large > and thus the latency for the frequency change to occur is large. > This was seen in Android UI responsiveness. The initial response > of the UI seems to be quite sluggish until after a while when the > cpufreq governors would catch up to the required MIPS. I know > that Patrick (Cc'd) did some experiments with conservative > governor but my understanding is that it still has this basic > problem. This appears to be a general problem with cpufreq on faster embedded systems, not just OMAP. I suspect that what we really need here is either tuning of the existing governors or new governors better adapted to embedded systems. I seem to remember from the last time I looked at this that I had a suspicion that the relatively high transition latencies embedded systems often have due to I2C PMICs really weren't helping here since the governors all tend to base their polling intervals on a multiple of those, resulting in poll times of the order of a second which are far too long for raising the frequency. Something like capping the latency used when raising the frequency or scaling the poll time based on the distance from the maximum frequency looked like a useful approach - certainly, claiming a very low transition latency avoids the UI-visible issue. -- 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
