ARCHIVED: [Kernel] Picasticks OC kernel built from LG source

Status
Not open for further replies.

picasticks

Well-known member
Feb 28, 2011
136
58
0
Visit site
Kudos to block944 for posting my little project here before I even had a chance to! I saw the incoming hits to the blog from androidcentral and it was ROFL time.

Anyways, the blog post with the details and blabber including source code is here:
Overclock Android kernel for Sprint Optimus S

But I'll summarize. The basic idea is to have the stability of the stock kernel (meaning both it should work and I won't have to rerelease it every other day), with maximum performance.

The kernel is compiled from VD source. There are a few changes to the kernel config to remove unnecessary stuff, so the binary winds up about 380K smaller than LG's.

The .zip uses koush's AnyKernel so you can flash it over top of stock VD or any VD ROM (I've had no issues with TR 1.8 and 1.8.2).

I've added overclocking. By default CPU scaling is from 245-748 MHz, but you can up this (or lower it) with SetCPU or similar.

I added the "interactive" CPUFreq governor for snappier UI coming out of idle. Now, because I'm doing AnyKernel and not changing the ramdisk image inside boot.img, your phone will still boot with "ondemand" by default (sorry, this is a downside to AnyKernel). You can change to "interactive" by doing any of (in increasing order of difficulty):
  • Use SetCPU to change it (and have it run on boot if you want). [or]
  • "echo 'interactive' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" and add this one-liner to any boot script if you want it to happen automatically on boot. [or]
  • Unpack the boot.img and edit /init.qcom.post_boot.sh in the ramdisk to use 'interactive', then repack and flash_image the new boot.img. This is what I do, and what you'd do if you were building a ROM with this kernel.

Before I paste the download link, I'll paste the standard disclaimer, thanks to ThundeROM:

We are not responsible for your device, SD cards, thermonuclear war, or the current economic crisis. Please do some research if you have any concerns about features included in this ROM before flashing it! YOU are choosing to make these modifications, we are simply making them available. - Steve Kondik

Current version (posted April 18): Download, copy to /sdcard, reboot to recovery and flash: picasticks-07.zip

Version history:
07 (posted April 18): picasticks-07.zip includes ext2, ext3, ext4 Linux filesystem drivers compiled as modules (no need to update if you don't want this)
06 (posted April 8): picasticks-06.zip config is identical to 05, but kernel now compiled with CodeSourcery toolchain with newer GCC
05 (posted April 3): picasticks-05.zip no known bugs; fixes issue in 04
Test version (posted April 2): picasticks-04-testA.zip (OC + interactive only; no kernel config changes from LG kernel, so good to use as baseline VD kernel. See thread around page 3 for info)
04 (posted March 31): picasticks-04.zip has UI lag problems due to choice of preempt RCU, do not recommend

Please let me know about any issues you run into. Be sure to report details like what ROM you are running and anything else that's relevant. Try to isolate the bug as much as possible and be sure that it is kernel-related.

I haven't had any, but if you have any issues with crashing or stability, please report what max CPU clock you used and what CPU governor, and try again with clock capped at 600 MHz and governor set to "ondemand" or "performance" to see if that makes any difference.
 
Last edited:

jstntp

/\C...D3\/
Feb 6, 2011
1,705
1,082
0
Visit site
Kudos to block944 for posting my little project here before I even had a chance to!.....

LMFAO!! I was following that post and contemplating trying "his" kernal too.

Nice to know the truth is out. Anyway, going to flash it now and i'll report issues, if any. I'll be running it on nROM 1.6.2 Thanks.
 

picasticks

Well-known member
Feb 28, 2011
136
58
0
Visit site
@Ksmith, thanks.

What is the difference between this and Xionia v13?

That's a good question! I will try to come up with a short answer but it is mostly a lot of details with the kernel config. Xionia is great, but the main reason I personally wanted a kernel like this is that it would just be LG source, so it would work as reliably as stock (I am not saying that Xionia isn't reliable, I don't know) and not need to be updated except when LG updates.

I have modified the C to do 2 things: overclocking, and the semi-official backport to add the interactive governor. (Xionia has both also.) I don't plan on doing a whole lot more of that, unless there are obvious big wins that are either in the android-kernel-msm7xxx tree or the generic tree (or else *really* solid). For now LG is putting out a new OS version really often so I don't think chasing down hardware bugs is my area. Xionia has a ton of patches to the C, mostly ported from CM7.

As far as the kernel config goes, the resulting stock kernel binary is 2.6M, mine is 2.3M, Xionia is 3.0M. Xionia adds many features that aren't in the stock kernel, off the top of my head: lots of filesystems like Ext4, support for some bluetooth and usb hw, LAN filesystems like CIFS, and all of the advanced router kernel stuff. You could use Xionia for WAN routing! If you diff our kernel configs you will see everything.

If lots of people ask for CIFS to stream MP3s of their Windows box, or particular crypto like Camellia, that's cool, I'll add popular kernel features as modules, but I want to keep the binary at least as small as stock. So, there you may prefer to use Xionia because you want Ext3 and NFS and it's all compiled in and you don't have to compile anything or feature request it from me.

Performance-wise, my goal is better performance than stock. I would guess that my kernel and Xionia are pretty close since the obvious performance improvements (overclocking and backporting interactive CPUFreq) are both there. There aren't any obvious performance boosts in the upstream kernel and all of LG's kernel config in the MSM area (where it counts) is basically spot-on. If people want to benchmark, that would be cool ... all I've done is the SetCPU benchmarks vs. stock and they all showed that my kernel with a 20% faster clock (748 MHz vs. stock 600 MHz) returned about 20% faster.

Anyway I hope some of that was useful. I think what zefie is doing is great and as someone interested in the kernel I follow Xionia, and if you are also really into the linux kernel then Xionia is going to give you more new stuff to try out. But, this project is more what I personally want to run everyday on my phone, a bit more conservative, but still kicking stock's ass.
 
  • Like
Reactions: 00_wrath_00

jstntp

/\C...D3\/
Feb 6, 2011
1,705
1,082
0
Visit site
snap20110331_224617.jpg
snap20110331_225108.jpg
snap20110331_224717.jpg
snap20110331_225528.jpg
 
  • Like
Reactions: picasticks

jstntp

/\C...D3\/
Feb 6, 2011
1,705
1,082
0
Visit site
Performance update:

With nROM 1.6.1, Max-748 Min-245 and Governor-Interactive, I did notice some lag and screen freezes for a few seconds when coming out of an app like Gallery or when downloading/uploading something or when wifi was connecting after the screen being off. But other than that, it ran smooth and no FC's that I could find.

I tried different Gov. settings and it did not seem to make a difference.
 

DoesItMatter

Well-known member
Dec 3, 2010
294
37
0
Visit site
Using this with nRom 1.6 - 768/480 - Interactive

Performance seems quite responsive, no F/C's or tombstones generated

Nice - I don't use or need any of the extra features - good kernel!
 

BDaught

Member
Mar 16, 2011
7
0
0
Visit site
Seems good so far. And the USB Storage works! That was my main problem with Xionia's. I still can't get mine over 806 without reboots.
 

picasticks

Well-known member
Feb 28, 2011
136
58
0
Visit site
I'm experiencing some lag with setcpu @ 245 748 interactive. I'll try and up the minimum a step.

I'll be very interested to know if it makes a difference. I just added the code for the interactive gov so I haven't had much chance to experiment with it yet, and if there's a better minimum that would be very useful.

Thanks to everybody for the benchmarks and feedback so far!
 

Robchaos_

Well-known member
Feb 18, 2010
141
50
0
Visit site
Well, I tried it for half the day and had to revert back to the stock kernel. I tried bumping up the min to a few steps up, and I also tried messing around with the lowmem settings (using lowmem app) . It just seemed to have trouble with freq. Transitions and lock screen lag.
 

00_wrath_00

Well-known member
Mar 11, 2011
657
82
0
Visit site
I tried it on NROM last night and was having a lot of lag regardless of the setting. Swiching to ThundeRom and see if my phone likes the combo lol


Sent from my LS670 using Tapatalk
 

zefie

Well-known member
Nov 15, 2010
844
634
0
Visit site
This kernel is the perfect option for just enabling overclocking, without any other speed hacks.

Compared to Xionia this kernel may feel slower, but so does stock. This is not a fault of this kernel, at all. The fact is Xionia uses many untested speed hacks.

Keep in mind the source code is not the only optimization. When I did kernels for the Samsung Moment I realized the importance of not just compiler flags, but compilers themselves.

Xionia is built with a special buildroot toolchain, then the Makefiles are hacked to add even more optimization.
The special toolchain supports optimizations that the standard Android Toolchain does not. If you have ever tried to compile Xionia from source, you may have gotten build errors. This is why.

I would suggest to pixa to compile using the Android Toolchain compiler v 4.3.3 from the froyo branch to best mimic being exactly like LG.

Also you may want to copy your .config to something else like thunderc_config then "make mrproper", then copy that file back to .config

a mrproper (more proper) is a cleaner version of "make clean" and will produce a nice clean build, but it deletes your .config (thus backing it up above). The result is you get "you@machine #1" instead of "you@machine #8", which is a dirty build (8 builds since last proper clean). I usually test using dirty builds then clean and release a clean build. It's probably unimportant and means nothing either way (i see ubuntu release with #30), but its just something I do. lol

Just some friendly suggestions though. :)
 
Last edited:
  • Like
Reactions: drewwalton19216801
Status
Not open for further replies.