"Madhusudhan" <madhu.cr@xxxxxx> writes: >> -----Original Message----- >> From: Mike Turquette [mailto:mturquette@xxxxxx] >> Sent: Thursday, October 29, 2009 4:38 PM >> To: Kevin Hilman >> Cc: Dasgupta, Romit; Cousson, Benoit; Chikkature Rajashekar, Madhusudhan; >> 'Paul Walmsley'; linux-omap@xxxxxxxxxxxxxxx; Titiano, Patrick >> Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource >> framework functions >> >> Kevin Hilman wrote: >> > "Dasgupta, Romit" <romit@xxxxxx> writes: >> > >> >> Hello Benoit, >> >> One comment below: >> >>> In fact, this is Mike who started that analysis. We discussed that >> internally and >> >>> our point is that if the CPUFreq ondemand or conservative heuristic is >> not able >> >>> to increase quickly enough the CPU need to handle correctly the UI, we >> have >> >>> to somehow improve or modify the governor in order to provide it a >> extra >> >>> information in term of constraint maybe in order to increase >> immediately the >> >>> frequency. >> >> The information as you mention needs to be supplied by the >> >> driver. The governor would then act on behalf of the driver! This >> >> begs for a new governor API or a signature change to an existing >> >> governor API. >> >> >> >>> This should not be done in the low level omap_pm code; this is not >> >>> the right level to do that. The issue is in the ondemand and must >> >>> be fixed there. >> >> At the end of the day it would still be the driver making the >> >> decision! >> > >> > No. The drivers can give hints about their requirements, but the >> > drivers don't make decisions that are system wide. The govenor acts >> > on behalf of the entire system based on multiple inputs, not any one >> > driver. >> > >> > Benoit's point (and I agree with) is that this is a *system wide* >> > problem that needs a *system wide* solution. I agree that tweaked or >> > new governor is the right approach to solving this for the long term, >> >> An assumption in this thread is that ondemand/conservative can't scale >> fast enough, but that is not true. The Android UI sluggishness >> mentioned by Benoit was solved by lowering the cpufreq >> transition_latency time from 10 million ns to 300,000ns. I have not >> gotten the exact worst case time that it takes for voltage to scale up >> and down from the hardware guys, but through some email exchanges it was >> agreed that this value is safe. >> >> I've pushed the patch that fixed transition_latency to the list. Please >> see thread "decrease cpufreq transition latency". This should hopefully >> cure a lot of performance/user experience pain and help us remove policy >> from drivers. >> > Hi Kevin, Mike, > > Let us consider the MMC scenario. Below are the throughput numbers with > different governors. > > Performance: > Write: 5.47MB/Sec > Read: 15.3MB/Sec > > Ondemand: > Write: 4.2 MB/Sec > Read: 9.8 MB/Sec > > Conservative: > Write: 4.9MB/Sec > Read: 12.16MB/Sec > > These numbers show that "conservative" is better than ondemand but the > throughput numbers are still less than "performance". No surprises there. > Instead, if the driver holds the vdd1 opp to opp3 the throughput numbers > were relatively close to "performance" governor. The logic I am talking > about is that the drivers should be intelligent enough to hold the opp at > Opp3 only when there is an active transfer. Once the transfer is done > release it back to opp1. Does this make sense? I think you're missing my point. What you're trying to do is to allow a driver to make a power vs. performance policy decision. You're assuming that the user (or system integrator) will always choose performance over power. What if the user is willing to accept a slightly slower system if it extends battery life? The point I'm trying to make is that these kinds of policy decisions simply do not belong in drivers. Kevin > Otherwise, do you guys think there is room to improve conservative governor > further? > > Regards, > Madhu > > >> > In the mean time, I have a couple ideas for experimentation. >> > >> > Ultimately, we're still talking about a power vs. perfomance tradeoff, >> > which is a system wide choice that should be left to the system >> > integrator (or maybe even end user.) If performance is desired over >> > power (like maybe when the UI is active), there are couple things that >> > could be done >> > >> > 1) Switch to performance governor, >> > >> > 2) or better, keep ondemand but use with CPUfreq policy changes >> > >> > With CPUfreq policies, you can change which OPPs are available to the >> > system. >> > >> > To see the currently available OPPs and the min/max settings: >> > >> > /sys/devices/system/cpu/cpu0/cpufreq # cat scaling_available_frequencies >> > 600000 550000 500000 250000 125000 >> > /sys/devices/system/cpu/cpu0/cpufreq # cat scaling_max_freq >> > 600000 >> > /sys/devices/system/cpu/cpu0/cpufreq # cat scaling_min_freq >> > 125000 >> > >> > To make OPP3 the minimum OPP, all that's needed is: >> > >> > /sys/devices/system/cpu/cpu0/cpufreq # echo 500000 > scaling_min_freq >> > >> > Changing the min freq is what you are trying to do from the MMC >> > driver. The difference here is that since this is a system wide >> > policy decision, it should be done a system wide level. >> > >> > Kevin >> > -- 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
