[Hero CDMA Android Development] waydownsouth:
kifCPU analysis

Not from these parts, but, certainly always on the lookout to squeeze a bit more performance/battery life out of my phone.

Years ago, I spent a huge amount of time trying to tweak as much battery life out of my ageing Linux laptop, so got reasonably proficient in tuning the cpufreq subsystem

I am far from an expert in shell scripting, but, know enough to get me in trouble... as such, please feel free to shoot this down if I'm off track.

kifCPU certainly has some merit in concept, I will however offer some constructive criticism.

First of all, lets look at the profiles: governor & tunables, we will look at the over temperature etc further down

Battery awake:interactive governor

echo 768000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 254000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 50000 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/min_sample_time

Makes sense... see no problems here

Although, reducing the sample time will reduce latency, at the expense of battery

Battery sleep:conservative

echo 264000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 264000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 100000 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/sampling_rate
echo 110000 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/sampling_rate_max
echo 90000 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/sampling_rate_min
echo 75 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/up_threshold

Why bother switching the governor at all if you are going to restrict the min & max to the same frequency? it can't scale.

You'd be better off just switching the governor to powersave & forgetting about the rest. (powersave will keep the cpu at min at all times)

Why bother switching the sampling rate & up_threshold if it can't scale?

You also try to switch the sampling_rate_max & sampling_rate_min... these are read only! They only tell you what the range of acceptable values are for sampling_rate

USB awake:interactive governor

echo 768000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 254000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 50000 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/min_sample_time

Ok, makes sense, but, see note above on sample time

USB sleep:ondemand governor

echo 264000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 264000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 350 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/powersave_bias
echo 100000 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
echo 110000 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate_max
echo 90000 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate_min
echo 75 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold

See the comments above under battery sleep... this is totally pointless

AC awake:smartass governor

echo 768000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 352000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 352000 > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_max_freq
echo 352000 > /sys/devices/system/cpu/cpu0/cpufreq/smartass/awake_min_freq
echo 352000 > /sys/devices/system/cpu/cpu0/cpufreq/smartass/up_min_freq
echo 352000 > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_wakeup_freq

The concept behind the smartass governor is to limit the max frequency when the device is asleep...

But, when the device goes to sleep, you switch to another governor, completely negating any benefits of using this governor in the first place

Furthermore, whats the point in setting the sleep frequencies when this governor will not be in use when sleeping?

AC sleep:interactive governor

echo 264000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 264000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 50000 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/min_sample_time

Same points as the other two sleep profiles.

& why do you need a low latency governor when the device is sleeping?

Now, on to the over temperature & battery capacity...

I have used the code from the sleep based profiles as they have the most glaring mistakes

if (( $capacity >= 25 ));then
echo 80000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
if (( $TEMP >= 350 )); then
(until (( $TEMP <= 275 ))
do
echo 100000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
done)
fi

I'm struggling with the logic of this one...

First of all:

The cpufreq system in my understanding will only accept values from your frequency table... usually found in /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

If this is meant to be some sort of temperature based limiter, then the implementation is wrong, it will only fire if $capacity >= 25... no regards to if you are over heating and battery is less than 25!

In a kind of pseudo code explanation of whats going on:

If capacity is above 25% (the following commands will only execute if this is true)

set max scaling frequency to 80000...

is this even an available frequency? if not, this does nothing.

Regardless, it could never stick... max freq cannot be less than the min freq of 264000 as set a few lines above.

If the temperature value is above 350, get stuck in a loop of echoing 10000 to scaling_min_freq... as fast as you can... without sleep... until the battery temp drops below 275.

As this would create 100% cpu utilisation, would the temperature drop & break out of the loop?

And, how would lowering the minimum scaling value help when your processor is maxed out? (I am assuming this is some sort of typo?)

Furthermore, is 10000 even a valid frequency from scaling_available_frequencies? it seems an unusual number

If so, not only are you stuck in a loop, CPU pegged, you are trying to echo an invalid frequency to a parameter that won't make one iota of difference...

But, at the end of it all, that section of code is mostly redundant for the sleep profiles, the chances of overheating when you're scaled back are slim to none. Question is, why even include it?

It makes a little more sense in the awake profiles, as you are scaling the processor back a little (by echoing to scaling_max_freq correctly), but, yet again, this will only fire if your battery is above 25%, ending up stuck in an infinite loop with no sleep, CPU pegged, until the temperature drops... (see note above)

Next query:

Why all the mount commands? At least twice for each state;

Before executing the function... mount rw then remount with noatime flags; Once in the function... again, mount rw then remount with noatime flags... Do you not like your phone?

As far as I can see, nothing in this script requires RW access to /system. (I'm assuming this is mtdblock3 on your devices?)

/sys only requires you to be root to write to it... same for the vm tweaks applied to /proc

If you are trying to get some performance gains with the noatime flag, this only needs to be done once, just after boot usually works fine...

In all, there is room for improvement in the implementation... But the concept is there, it can only get better.

WDS