[Galaxy S II Original Android Development] AndreiLux:
It seems people are still confused about how ondemand works, and I posted this also in the REF thread, and more people should read it here too.

___________

Sample (n)

max_load_freq is initialized to 0. The governor polls the CPU driver to tell it what "average" frequency it was at since the previous sampling.

It polls the wall_time from the CPU, it's a continuous counter storing the uptime of the CPU. It polls the idle_time, also a counter storing the amount of time a CPU is idle. It calculates the load by taking the wall_time minus the idle_time and you end up with a percentage which describes the load of the cpu. ( load = 100 * (wall_time - idle_time) / wall_time; )

It takes the load times the average frequency to calculate an arbitrary frequency which describes how much speed the device theoretically needs for 100% of the work done on it. This is load_freq.

Because we have multiple CPU cores, and we are running them on the same frequency and cannot run them on asychronous frequencies, the same thing is done for each core. max_load_freq is then the maximum load frequency as calculated above for each core. max_load_freq is not an actual frequency run by the CPU.

The governor can now splits into two things:

If max_load_freq is greater than up_threshold * current frequency, then it will tell the CPU driver to scale to maximum frequency. The rate multiplier is set by sampling_down_factor. Keep in mind that smooth scaling is done by the CPU driver and not the governor.

The next sample will be (n+sampling_down_factor).

If max_load_freq is smaller than (up_threshold - down_differential) * current frequency, then it calculates an arbitrary frequency which will hold the current maximum load for the next sample without triggering up_threshold. down_differential is there just to act as a safeguard to give the workload more flexibility so that it won't scale down too aggressively. This next arbitrary frequency is passed onto the CPU driver and he will look into the frequency table and change to the state with the next-highest frequency.

The next sample will be (n+1).

_______________________________________

Now if you do the math correctly in your example; first of all, now you know max_load_freq cannot be 1200 like in your example. Let's assume it's 587. Also remember we're using percentages here, you calculated with integers.

587 / (0.85 - 0.05) = 733

So the governor tells the CPU driver to set it to 733MHz, the CPU driver rounds that up to the next frequency in the table which would be 800MHz. Theoretically now, assuming the load will be constant, the CPU will already be at a frequency capable of supporting it, and sure of not triggering the up_threshold.

Now if you see in the numbers above, how it's stupid to have a high down_differential. The target frequency is getting rounded up once by the up_threshold, once by the down_differential, and then at the end again by scaling it to an actual frequency state on the CPU. In that above example with those thresholds, you have a CPU which will be physically idle for 36% (!!) of the time. This is why ondemand thresholds are way different than interactive based ones, and you can get away with very high thresholds.