Been working on Galaxy Nexus kernels almost exclusively for a while. It's not the easiest kernel to work on. The omap4 architecture seems to be very picky about every little change, so I could make a seemingly harmless small mod and BAM the battery drains 2x as fast.
Anyway, I have a Rootzwiki thread, which sees a lot of traffic and I can't usually keep up with the discussions there. I thought maybe I can use my blogger.com page (which I haven't used in a while) to collect some feature requests from users. So what about it? If you'd love to see a feature please post it here. Keep in mind that I'd probably end up getting to less than 10% of the requests, as this is a "minimalistic" kernel and all. :) Please try to post feature requests only, all other discussions should go back to the Rootzwiki thread.
Monday, April 16, 2012
Wednesday, October 5, 2011
CPU Governors
I've been tinkering around with cpu governors quite a bit in my Android kernels. I believe governors are a single most effective way to improve or diminish the "user perceivable" performance of the device.
Here's my personal take on governors that are included in stock and other custom kernels:
performance - max speed all the time
powersave - lowest speed all the time
conservative - slow ramp-up
The next few get a bit more complex. ondemand, interactive, and smartass all try to pretty much do the same thing: perform well and power efficient. But the way they approach their goals are very different (ie. their algorithms are very different).
1) ondemand - been in linux for a long time and we got really smart linux kernel developers working on it and the code gets reviewed by really smart people. At the same time this governor is really designed to work on desktops, servers, phones, etc - a universal solution.
2) interactive - developed by CM (I think), tuned for performance. Instead of sampling at every interval like ondemand, it determines how to scale up when cpu comes out of idle.
3) smartass - developed by erasmux for his android kernel. Popular for its ability to use android's onboard suspend mechanism to keep the phone below a certain clock speed when screen is turned off. Also does slow ramp-up like the conservative governor.
Instead of the above, here are the three governors that I include in my custom kernels:
Here's my personal take on governors that are included in stock and other custom kernels:
performance - max speed all the time
powersave - lowest speed all the time
conservative - slow ramp-up
The next few get a bit more complex. ondemand, interactive, and smartass all try to pretty much do the same thing: perform well and power efficient. But the way they approach their goals are very different (ie. their algorithms are very different).
1) ondemand - been in linux for a long time and we got really smart linux kernel developers working on it and the code gets reviewed by really smart people. At the same time this governor is really designed to work on desktops, servers, phones, etc - a universal solution.
2) interactive - developed by CM (I think), tuned for performance. Instead of sampling at every interval like ondemand, it determines how to scale up when cpu comes out of idle.
3) smartass - developed by erasmux for his android kernel. Popular for its ability to use android's onboard suspend mechanism to keep the phone below a certain clock speed when screen is turned off. Also does slow ramp-up like the conservative governor.
Instead of the above, here are the three governors that I include in my custom kernels:
- interactiveX - it's the interactive governor from CM, but I added suspend/wake logic so when the phone screen is off it runs at below 400Mhz. Also, I modified its code some more to minimize unnecessary cpu spikes above a certain threshold if kernel is heavily overclocked. (Most devices are unstable above a certain speed when it's heavily overclocked, and it's the quick jump to top speed that usually locks up the phone.)
I like this governor because it's simple and fast. - ondemandX - ondemand governor code from latest linux (3.0 at the moment) source *plus* the suspend/wake logic described above. No further optimization is done.
- smartass - smartass code from erasmux, but I wasn't happy with its performance so I tuned it for quicker ramp up in speed. It has the same suspend/wake logic as ondemandX, and similar stability optimizations as interactiveX. (update: smartassV2 is new and currently I include the v2 in my kernels without optimizing further).
Tuesday, September 27, 2011
Kernels
Building kernels has been my thing lately. Been developing for:
- Thunderbolt
- Droid Charge
- Samsung Fascinate/Mesmerize/Showcase
- Samsung Galaxy Tab 7"
You can find my threads on http://rootzwiki.com/.
Friday, May 20, 2011
DX/D2 tweaks new version (man it's been a while)
Sorry guys, I've been pretty busy developing kernels for thunderbolt in the recent weeks in my spare time. Which i don't have a lot of due to a full time job (in case someone from work is reading this). ;)
Here's an updated zip for DX/D2 users. If you're already on thunderbolt, you shouldn't have to flash this zip (although it won't fail) - you should be flashing my kernels instead! If you're on someone else's kernel and flashing this zip to get my tweaks shame on you! :-)
v7.1 (download)
To verify that all the tweaks are in place:
v7.1
NOTE to D1 users: Been working with Liquid to develop kernels for D1 as well. Still work in progress.
Here's an updated zip for DX/D2 users. If you're already on thunderbolt, you shouldn't have to flash this zip (although it won't fail) - you should be flashing my kernels instead! If you're on someone else's kernel and flashing this zip to get my tweaks shame on you! :-)
v7.1 (download)
To verify that all the tweaks are in place:
- Open Terminal Emulator
- su
- checktweak.sh
v7.1
- Latest busybox compiled by yours truly.
- Modified enable scripts to work on GB ROMs.
- Easier to run check script (see above).
- SD card speed boost.
NOTE to D1 users: Been working with Liquid to develop kernels for D1 as well. Still work in progress.
Sunday, April 10, 2011
Not so universal for original Droid
I was recently approached by Jason at Droidforums to see if I can make a zip for my tweaks for Droid 1. Working with him closely (since I don't have a D1) I was able to come up with a slightly crippled version of my mods for Droid 1 running Project Elite ROM (but it should work for any ROMs that have init.d support).
Download
To check to see if the mods are working: open Terminal Emulator and type "bash /system/etc/imoseyon/checkimosey.sh" without quotes.
I'll try my best to further enhance the mods but I'll need some help from other D1 users. :)
Download
To check to see if the mods are working: open Terminal Emulator and type "bash /system/etc/imoseyon/checkimosey.sh" without quotes.
I'll try my best to further enhance the mods but I'll need some help from other D1 users. :)
Tuesday, April 5, 2011
minimal kernel for tbolt
Been messing with compiling kernels for my thunderbolt. You can read about it here: http://goo.gl/hmhyb
More details on this later. Combing through the kernel code for more tweaking opportunities. ;)
More details on this later. Combing through the kernel code for more tweaking opportunities. ;)
Friday, April 1, 2011
Why swap?
Why not? ;) If you think with 768MB of RAM on the thunderbolt you'd have way more memory than you'd ever need, then think again. A lot of the memory is taken up by cache and buffers, which are also used pretty heavily with my tweaks.
For those of you that are new to Linux (or other UNIX variants), you'd probably heard the term "virtual memory". Swap is pretty much that - a way to extend your physical memory. Your OS moves the less accessed memory pages to slower, and cheaper storage medium. This frees up RAM for things that require the speed. And guess what? On almost all android devices you'll find tons of flash memory which are going to provide near RAM access speed for your swap space.
But setting up swap alone isn't going to do much. In fact, it could do more harm than good. You'd also want to adjust some OS/kernel related settings so your phone/device can use swap effectively.
You want to primarily look at two settings: vm.swappiness and minfree.
vm.swappiness is a no brainer. The lower the number less swap the OS is going to use, the higher the more swap. If you set it to 0 it's not going to use swap at all, 100 it's going to use a lot of swap. If you set it to say 1 it would use swap only when absolutely necessary. I recommend 40 on a 200MB swap file.
minfree is another tricky one. To really get the full benefit of swap, I think you want minfree to "work less", ie. kill active and semi-active apps less frequently. This will allow all of your frequently used apps to stay in RAM. Something like this would work well:
echo "100,200,20000,20000,20000,25000" > /sys/module/lowmemorykiller/parameters/minfree
Finally, you'd need a kernel that supports swap. Unfortunately if your bootloader is locked (ie. DX/D2) you're not going to get custom kernels that will support swap. I've tested swap on some custom kernels on the Tbolt and the Gtab and it works well. If you're running a kernel that supports swap, download and flash my zip to create and enable swap; the zip will also adjust swappiness and minfree accordingly if swap is enabled.
One final note on this is some technical stuff on why I chose to use internal flash for swap rather than the sdcard - internal flash performs better:
For those of you that are new to Linux (or other UNIX variants), you'd probably heard the term "virtual memory". Swap is pretty much that - a way to extend your physical memory. Your OS moves the less accessed memory pages to slower, and cheaper storage medium. This frees up RAM for things that require the speed. And guess what? On almost all android devices you'll find tons of flash memory which are going to provide near RAM access speed for your swap space.
But setting up swap alone isn't going to do much. In fact, it could do more harm than good. You'd also want to adjust some OS/kernel related settings so your phone/device can use swap effectively.
You want to primarily look at two settings: vm.swappiness and minfree.
vm.swappiness is a no brainer. The lower the number less swap the OS is going to use, the higher the more swap. If you set it to 0 it's not going to use swap at all, 100 it's going to use a lot of swap. If you set it to say 1 it would use swap only when absolutely necessary. I recommend 40 on a 200MB swap file.
minfree is another tricky one. To really get the full benefit of swap, I think you want minfree to "work less", ie. kill active and semi-active apps less frequently. This will allow all of your frequently used apps to stay in RAM. Something like this would work well:
echo "100,200,20000,20000,20000,25000" > /sys/module/lowmemorykiller/parameters/minfree
Finally, you'd need a kernel that supports swap. Unfortunately if your bootloader is locked (ie. DX/D2) you're not going to get custom kernels that will support swap. I've tested swap on some custom kernels on the Tbolt and the Gtab and it works well. If you're running a kernel that supports swap, download and flash my zip to create and enable swap; the zip will also adjust swappiness and minfree accordingly if swap is enabled.
One final note on this is some technical stuff on why I chose to use internal flash for swap rather than the sdcard - internal flash performs better:
sh-3.2# hdparm -Tt /dev/block/mmcblk0p26
/dev/block/mmcblk0p26:
Timing buffer-cache reads: hdparm: HDIO_DRIVE_CMD: Inappropriate ioctl for device
326 MB in 0.51 seconds = 653840 kB/s
Timing buffered disk reads: 52 MB in 3.01 seconds = 17683 kB/s
hdparm: HDIO_DRIVE_CMD: Inappropriate ioctl for device
sh-3.2# hdparm -Tt /dev/block/vold/179:33
/dev/block/vold/179:33:
Timing buffer-cache reads: hdparm: HDIO_DRIVE_CMD: Inappropriate ioctl for device
218 MB in 0.51 seconds = 437047 kB/s
Timing buffered disk reads: 15 MB in 3.03 seconds = 5054 kB/s
hdparm: HDIO_DRIVE_CMD: Inappropriate ioctl for device
sh-3.2# time busybox dd if=/dev/zero of=/mnt/sdcard/test bs=1k count=100000
100000+0 records in
100000+0 records out
real 0m17.159s
user 0m0.070s
sys 0m2.710s
sh-3.2# time busybox dd if=/dev/zero of=/data/test bs=1k count=100000
100000+0 records in
100000+0 records out
real 0m12.202s
user 0m0.100s
sys 0m2.960s
Subscribe to:
Posts (Atom)