[Kernel-.33.3][DIET][05/02] CM 5.0.6, 8 MB+ RAM, Hybrid AVS **STABLE**, Optional OC

I

Ivan Dimkovic

Senior Member
Oct 13, 2006
170
0
0
Mar 29, 2010 at 12:40 PM
Diet Android Kernel 2.6.33.2 by PsyQ

I am releasing the kernel which I use by myself :) I removed most of the debugging options useful for kernel/driver debugging and maxed-out possible compiler optimizations. It has Hybrid AVS support using IntersectRaven's improved method as well as optional overclocking (see note)

These kernels feature:

* Hybrid Adaptive Voltage Scaling for extra battery life
* Optional 1.1 GHz Overclocking Support
* Extra 8 MB of RAM reclaimed from Camera
* Based on Cyanogen's 5.0.6 kernel
* Maximum possible compiler optimizations (loop unrolling, tree vectorization, NEON, Cortex A8 compiler tuning, armv7a target, and many more)
* Removed all unnecessary features from the kernel configuration, including debugging options (these kernels are not useful for kernel debugging / driver development)
* All cpufreq governors (ondemand, powersave, conservative, ...) for people that want to tweak the CPU frequency scaling

Following kernels are available:

diet_2.6.33.3.hybrid_avs_800mv.zip --> Hybrid AVS support, goes down to 0.8 volts and has stock frequency (998 MHz) as max.

diet_2.6.33.3.hybrid_avs_800mv_OC.zip--> EXPERIMENTAL Hybrid AVS with overclocking to 1.1 GHz (0.8v min voltage)

diet_2.6.33.3.hybrid_avs_925mv.zip --> Hybrid AVS support, goes down to 0.925 volts and has stock frequency (998 MHz) as max.

diet_2.6.33.3.hybrid_avs_925mv_OC.zip--> EXPERIMENTAL Hybrid AVS with overclocking to 1.1 GHz. (0.925v min voltage)

To use it, flash the zimage with fastboot and push the bcm4329.ko to the /system/lib/modules:

Code: 
[power off your phone and boot into fastboot]
fastboot flash zimage zImage
[reboot]
adb remount
adb push bcm4329.ko /system/lib/modules/bcm4329.ko
Pushing of the bcm4329.ko is necessary as WiFi support would be broken otherwise. If you don't do it, WiFi will not work.

Changelog:

Code: 
V1.11 - Update - May/02nd/2010

  - Moved to 2.6.33.3 Kernel

V1.10 - Update - Apr/26th/2010

  - Changed floating point model to VFP
  - There are two AVS versions with different lowest voltage limits (800/925mv)
    
V1.09 - Update

  - Implemented IntersectRaven's Hybrid AVS method
  - Synced with the latest code snapshot of CM kernel

V1.08 - Update
  
  - Non AVS kernel is now undervolted down to 0.925v
  - Kernel RCU is now of uniprocessor type, saving memory
  - DMA speedup patch from latest CM source
  - Removed "loopback" file device (this is not related to network)
  - Further compiler optimizations

V1.07 - Update

  - 8 MB RAM reclaimed from Camera
  - Further kernel trimming 
  - AVS is now available with 0.925v and 0.850v flavors
  - Some attempts to make AVS more stable (still work in progress)

V1.06 - Update

  - Moved to kernel 2.6.33.2 from Cyanogen's 5.0.5.6 source
  - AVS kernels are capable of undervolting down to 0.925v instead of 1.000v
  - Minor cleanups

V1.05 - Update
  
  - Further fixes in AVS Support (thx intersectRaven!)
  
V1.04 - Update

  - Fixed bugs in AVS Support
  - More kernel tweaks
  - Removed "normal" version of the kernel, as _xtra seems to be stable enough
  - Added non-overclocked AVS kernel for maximum battery life  

V1.03 - Update

- Added Experimental Adaptive Voltage Support (AVS)
- Currently AVS is "for test only", and this kernel has debug support and no loop unrolling

V1.02 - Update

- Switched to CFQ I/O Scheduler
- Removed some more stuff (e.g. 10 Gbit Ethernet Support)

V1.01 - Update

- Added Conservative Governor
- Fixed table lookup bug (thanks pershoot!)

V1.0 - Initial Release

- Based on CyanogenMod 5.0.5.3 source
- Overclocking Support (1.1 GHz)
- Undervolted
- Optional extra undervolt (see attachments - _xtra is additional UV)
- Added Powersave CPU governor
- Removed most of the debugging stuff from Kernel (which makes this kernel useless for kernel debugging!)
- Even more C compiler optimizations (almost -O3 level + extra stuff, like loop unrolling, etc...)
- Audioboost patch

For other kernel developers - you can find the source code here (note that for AVS support you need AVS sources from ChromeOS):

http://github.com/psyq321/nexus_one_kernel_additions
 

Attachments

Last edited:
S

seanowns

Senior Member
May 30, 2009
465
40
0
Mar 29, 2010 at 12:58 PM
Grrr!!! checked for updated version right before leaving for work, and just missed it!

I am using the one you posted in the other forum without any issues. Does it possess the same undervolting as the Xtra version?
 
I

Ivan Dimkovic

Senior Member
Oct 13, 2006
170
0
0
Mar 29, 2010 at 1:09 PM
Yes, _xtra is using same undervolt as the version from yesterday.

Additionally, this version contains more optimizations (loop unrolling) that I managed to cram-in by removing more debug options of the kernel (otherwise it would not fit)
 
I

Ivan Dimkovic

Senior Member
Oct 13, 2006
170
0
0
Mar 29, 2010 at 3:13 PM
xPatriicK said:
What is loop unrolling?
Click to expand...
Loop unrolling is the optimization technique used by modern compilers to potentially speed-up execution by decreasing overhead of the loop passes.

For example, imagine that you have a loop, that does something 4 times:

Code: 
for(x=0; x<4; x++) {
  do_something;
}
In this case, some % of the execution will be checking if the x is less than 4, and if no - "doing_something" again. This check has to be performed for every step (so, it is done 4 times)

Now, if you unroll this loop, it would look like this:

Code: 
do_something; x++;
do_something; x++;
do_something; x++;
do_something; x++;
^ So, in this case, we completely eliminated checks.

Or, if the loop is much bigger (say, x goes up to 800):

Code: 
for(x=0; x<800; x+=4) {
  do_something;
  do_something[x+1];
  do_something[x+2];
  do_something[x+3];
}
See? In this case, you reduce the number of condition checks for bigger loops.

This can sometimes make code faster - but the downside is that it makes the code bigger (which is obvious even in those examples above).

In Android Kernel 2.6.33.1 case - loop unrolling increases zImage size by ~350K. If I didn't strip debugging stuff out, zImage would be too big to fit on Nexus One.

Fortunately, there was approx. 400K to be saved by just kicking out features that enable kernel debugging. I don't think most of the people need that. These features are useful for kernel and driver developers, but most of others can perfectly live without them :)
 
sir*mez

sir*mez

Senior Member
Nov 7, 2007
1,400
310
113
NYC
Mar 29, 2010 at 3:20 PM
Ivan Dimkovic said:
Loop unrolling is the optimization technique used by modern compilers to potentially speed-up execution by decreasing overhead of the loop passes.

For example, imagine that you have a loop, that does something 4 times:

Code: 
for(x=0; x<4; x++) {
  do_something;
}
In this case, some % of the execution will be checking if the x is less than 4, and if no - "doing_something" again. This check has to be performed for every step (so, it is done 4 times)

Now, if you unroll this loop, it would look like this:

Code: 
do_something; x++;
do_something; x++;
do_something; x++;
do_something; x++;
^ So, in this case, we completely eliminated checks.

Or, if the loop is much bigger (say, x goes up to 800):

Code: 
for(x=0; x<800; x+=4) {
  do_something;
  do_something[x+1];
  do_something[x+2];
  do_something[x+3];
}
See? In this case, you reduce the number of condition checks for bigger loops.

This can sometimes make code faster - but the downside is that it makes the code bigger (which is obvious even in those examples above).

In Android Kernel 2.6.33.1 case - loop unrolling increases zImage size by ~350K. If I didn't strip debugging stuff out, zImage would be too big to fit on Nexus One.

Fortunately, there was approx. 400K to be saved by just kicking out features that enable kernel debugging. I don't think most of the people need that. These features are useful for kernel and driver developers, but most of others can perfectly live without them :)
Click to expand...
on point. i like what i see. i will try this out.
 
I

intersectRaven

Senior Member
Mar 13, 2010
2,260
1,558
0
www.intersectraven.net
Mar 29, 2010 at 3:48 PM
xPatriicK said:
standby 245/245 governor is better than on demand?
Click to expand...
It's not necessarily better. It depends on what you're optimizing for. For example, powersave governor optimizes for power savings in return for slowest clock speed which may be apparent when using CPU intensive apps. Ondemand tries to balance it somewhat while giving more importance to CPU speed since it clocks the CPU back to full speed whenever an app runs and downclocking when appropriate. The conservative governor I use in my kernel also tries to balance this but gives more importance to power savings since when an app runs it slowly ramps up the clock speed until the app finishes. Hope this clears it up! ;)
 
I

Ivan Dimkovic

Senior Member
Oct 13, 2006
170
0
0
Mar 29, 2010 at 3:53 PM
Note that powersave might actually consume more power at the end if you do some intensive work.

Why? Because it will force CPU to stay at the lower clock, even if the task could be completet much quicker with the higher clock.

At the end - it could very well be that running the task quicker @higher clock speed could consume less power total!

Unfortunately, there is no easy way to test what is better, unless someone writes a script that performs some tasks repeatedly until battery dies, and compares the baterry life between different CPU scaling strategies.

I'd definitely not use powersave governor. Rather, I'd play with the "up threshold" and "profiles" in SetCPU to make the CPU frequency scaling more conservative.
 
You must log in or register to reply here.

New posts

Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone