Tuesday, 26 June 2012

Stable Nexus S kernel release 3.0.36-14

So, another stable release. A few updates, a new base for the kernel and of course merged up to the latest mainline stable release. It should be faster and more stable, but there is nothing mind blowing here, except perhaps the addition of Voodoo sound by popular demand.

I spent lots of time benchmarking toolchains and kernel sources, and I’ve settled on the one which appears to be the fastest and most stable.

I also built non-essential drivers as modules so they aren’t in the zImage. This has the advantage of code not being loaded for features which aren’t being used by the majority of users. This has the other advantage that if users request a particular driver/filesystem/etc, I can easily add it as a module without affecting users who aren’t using it. Unfortunately, modprobe is broken as it looks for the modules in the wrong place, so you will need to load the modules with insmod, and they are located in /system/lib/modules

Wifi will also work now if installed on a CM based ROM, as they moved the module and broke compatibility with stock.

Changelog:

  • Third stable release, slightly different base this time. The kernel is based on AOSP common (3.0.31) with the AOSP Samsung kernel (3.0.8) patches applied on top. It has then been merged to 3.0.36 from mainline.
  • Voodoo sound v10 patches applied.
  • Wifi will now work if installed with a CM based ROM.
  • Moved cifs and utf8 from the zImage into /system/lib/modules
  • Various compiler warnings and section mismatches fixed
  • Disabled a stack of debug options resulting in a slightly faster kernel
  • Compiled with a FSF GCC 4.6.3 toolchain built with crosstool-ng – .config here for interested people.

Features/Config:

  • Deadline I/O scheduler adjusted for flash for lowest I/O latencies
  • Ondemand governor adjusted to sample less at higher frequencies to reduce overhead
  • Config: As stock AOSP with the following modifications: Deadline I/O scheduler, Ondemand CPU governor, Tiny Preempt RCU, Voodoo sound
  • Additional modules provided: CIFS, utf8
  • PM fast for wifi

 

Available here.

 

Dismissed ideas:

If something appears on here, the answer is no, so please don’t ask for it again.

  • Interactive CPU governor – no improvement in responsiveness, but much more expensive in terms of CPU usage
  • Conservative GPU governor – worse responsiveness, higher latency, slower race to idle so in theory could result in higher power usage depending on usage model. Perhaps it is useful on older hardware, but it’s not particularly useful on our phones
  • Any other CPU governor – lets just cut to the chase, ondemand is the best and cheapest one I have tried. It also doesn’t involve maintaining non-mainline code, it is the one I like, it’s tried, tested, stable, works extremely well and is mainlined, unlike governor X, Y & Z
  • Linaro GCC – Surprisingly enough, Linaro GCC actually produces a slightly worse performing kernel than FSF GCC
  • CFLAG (compiler) optimisations – Tested various optimisations with various toolchains, none made any measurable improvement, some made the kernel perform slightly worse
  • Overclock – I did consider implementing some overclock, basically to improve the boot time more than anything else. After trying it, it made no significant difference so I decided it wasn’t worth the possible instability it could bring. Unfortunately, the hummingbird apps processor is still gutless, even with overclock
  • Voodoo colour – I considered this, but I don’t believe it adds value to the kernel. It’s not a necessary feature and there are plenty of kernels with this. As regards colours, I also tested reverting the change which was brought about in 2.3.3, but it left the screen with a blue tinge so backed it out again
  • BLN – it’s very hackish and totally unnecessary and certainly does not add any value to the kernel. Again, there are plenty of other kernels with this awful feature
  • Deep Idle – I’m not convinced that it is stable enough. It wasn’t implemented by Samsung/Google for some reason or other, lets just leave it at that

4 comments:

  1. Please put your sources code or patchset on the Internet.

    If you don't do that, you will break the law.

    ReplyDelete
  2. My source is always available on my Github, so kindly sod off.

    ReplyDelete
  3. I don't see MTP in dismissed ideas. Any chance of implementing it in your kernel (or you can tell me it's a stupid idea)? I found it kinda handy on Bedalus kernel (the only handy thing in that kernel, I switched back to your immidiatelly).

    ReplyDelete
  4. Hi.

    So you implemented Overclock but didn't see much improvement in boot time. How about when playing a game that uses max hardware capacity of the phone? In my opinion most users overclock when its time to play a game that lags or does not perform as it should because our phone is getting older. I usually OCed when i was about to play a game and when i was done i put it back on stock cpu frequency. Would like to know your opinion about this. You probably didn't consider it because you dont play games on your phone(i think i read that on your xda thread but i may be wrong)

    ReplyDelete