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

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

---

Do you use the xtra version, if so have you noticed any problems

---

Nice release, will definitely try sometime.

---

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?

---

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)

---

What is loop unrolling?

---

Awesome, I'll pull the config to see what you have done...

---

just installed on my device. so far so good, using the extra undervolt. booted fine and everything so will report back later if I notice anything weird.

---

Hi man, in first thanks for this work...
Now can u tell me how can i use your kernel?
Thanks in advanced

---

just
[power off your phone and boot into fastboot]
fastboot flash zimage zImage
[reboot]
adb remount
adb push bcm4329.ko system/lib/modules/bcm4329.ko

---

interesting...I've been experimenting with the compiler optimizations in my own build...it made the kernel bigger although I feel a bit more responsiveness now...almost not noticeable but I think its there...

---

xPatriicK said:
What is loop unrolling?
Click to expand...
Click to collapse
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

---

Alright, thank you!
will try _xtra when Paul released the new Desire cam. Thanks for your work

---

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...
Click to collapse
on point. i like what i see. i will try this out.

---

If I use the powersave governor option, SetCPU always show it running at minimum 245MHz. Is it working as expected?

---

bethedealer said:
If I use the powersave governor option, SetCPU always show it running at minimum 245MHz. Is it working as expected?
Click to expand...
Click to collapse
That's fine since the powersave governor clocks it to the lowest for maximum power savings.

---

standby 245/245 governor is better than on demand?

---

xPatriicK said:
standby 245/245 governor is better than on demand?
Click to expand...
Click to collapse
Curious about this too!

---

xPatriicK said:
standby 245/245 governor is better than on demand?
Click to expand...
Click to collapse
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!

---

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.