[Nexus 7 Original Development] The Gingerbread Man:
This is a repost from yellowdie, I can't find the exact post so its just a copy paste I'm afraid. Anyway this for those of you new to this 'game' (and its a biatch btw hahahaha) this post summarizes the behavior around interactive governor so you can see how it works.

Please take note this post is taken from galaxy nexus thread so the default values indicated probably won't watch up as its a different device. Of course credit to yellowdie for his fantastic explanation on all this!

Repost as follows as below, no need to thank find the post and thank yellowdie

THIS POST WILL BE A RECAP OF THE LAST FEW PAGES OF RESEARCH!

This was my original settings that I've been using for weeks:

So to make the short hand easier, we kept it in that order and just said: 20000/50/40000/20000 became 20k/50/40k/20k became 2/5/4/2. Make sense?

Here is a breakdown of what they each mean:

This is a good explanation that I wrote back on page 3038:

So Google's default is 10/5/6/2. Lower numbers are all better for performance except min_sample_time (there higher is faster). So our goal is to find a sweet spot.

The default 10 is for "Once speed is set to hispeed_freq, wait for this long before bumping speed higher in response to continued high load." So we think 10 is too high, but if you go too low, then you'll be using the higher freqs a lot more than you need and it will hurt the battery. So we are leaning towards 6 (60000) for above_hispeed_delay.

The default 5 is for "when the CPU hits X% amount of load, then jump to the hispeed_freq." Again if this one is too low then it will cause the higher freqs to be used more often then they need, so we actually turn go_hispeed_load up a little bit to 7 (70).

The default 6 is for "how long do I wait before lowering the clock speed from what it's currently at." So the lower we put this, the better battery will be. We're still trying to decide between 3 (30000) and 5 (50000). Osm0sis is getting more lag at lower levels, and finds the best performance mark at 5. So we turn min_sample_time down a little from stock to help with the battery.

The default 2 is for "wait this long before changing the clockspeeds from what it's at now." While technically 2 sounds better because it's changing more often, Franco believes that by setting the timer_rate to be the same thing as the CPU sample_rate (which is preset at 30000), then that will make the CPU more efficient at switching. So we increased it from 2 (20000) to 3 (30000).

So TO RECAP: Using the stuff from above, Google's defaults for these settings are 10/5/6/2 and we are changing them to 6/7/3/3 or 6/7/5/3 (again, still testing that third number for the min_sample_time).

Does that make sense for everyone interested in following along? Any questions? Feel free to try out these settings yourself (the easiest way is with Franco's app or something like Trickster). We want as much feedback as possible on this.

The next kernel release will have the totally tweaked settings for everyone to test without having to change their own stuff.

---------- Post added at 01:15 AM ---------- Previous post was at 12:58 AM ----------

Yes definitely a UI improvement is felt, feels great and like someone else said it feels quite iproduct like. This is a good place to work from but personally think the hispeed freq might be better at 760 to save some battery (makes no difference in switching apps) and to me most of the boost was felt from bumping up high load threshold to 95 the rest felt minor improvements but notable overall. I'm going to see if I can improve this further ;)