[Q] About the ~200 line Linux kernel patch that does wonders - Galaxy S I9000 Q&A, Help & Troubleshooting

Hello, guys!
I guess most of you know about this "magic patch" that significantly boosts Linux speed. It's going to be merged in the 2.6.38 branch and it's shipping with Ubuntu Natty too. But this kernel patch can be applied to a previous kernel as well, just rebuilding it with this 224 magical lines of code.
What I wanted to know is if it's possibile to rebuild our kernels with this patch, if it is already, or if it's possibile but won't have significant boosts on Android devices.
You may read more about this on Phoronix. On the 2nd page there are video demos for lazy ones!

This has been discussed here twice &found not to help because we dont use harddisk.
Sent from my GT-I9000 using XDA App

was it "proven" or "theorized" ?

You can look it up here in dev. Search
Sent from my GT-I9000 using XDA App

ragin said:
This has been discussed here twice &found not to help because we dont use harddisk.
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
Thank you, but can you please link the thread with this discussion? I can't seem to find it. Also, this patch regards CPU, not hard disks.

this patch will be officially introduced in the 2.6.38 kernel..
also, this kernel will have about 50% more speed increase, due to the 200 lines patch and another issue resolved after it .. in general the upcoming kernel will be blazingly fast !!
there is a script that tries to do the same as the patch for earlier kernels. which I use on my Ubuntu laptop, and yes major performance increase !!
I tried to apply it to my previous phone (HTC Hero), but didn't work. I also asked Cyanogen on his twitter, but didn't care to give me an answer..
finally I gave up, and decided to wait for the next Android version that will have the 2.6.38 in the future..

MaXo64 said:
this patch will be officially introduced in the 2.6.38 kernel..
also, this kernel will have about 50% more speed increase, due to the 200 lines patch and another issue resolved after it .. in general the upcoming kernel will be blazingly fast !!
there is a script that tries to do the same as the patch for earlier kernels. which I use on my Ubuntu laptop, and yes major performance increase !!
I tried to apply it to my previous phone (HTC Hero), but didn't work. I also asked Cyanogen on his twitter, but didn't care to give me an answer..
finally I gave up, and decided to wait for the next Android version that will have the 2.6.38 in the future..
Click to expand...
Click to collapse
I'm using that script too on Maverick! I don't think there should be a significant increase in responsiveness if you apply it on high-end systems, but our SGS might benefit from it (as my old dual core system).
You say it didn't work on your Hero, but were there any errors in dmesg or you didn't find any significant change in speed?

thunderteaser said:
I'm using that script too on Maverick! I don't think there should be a significant increase in responsiveness if you apply it on high-end systems, but our SGS might benefit from it (as my old dual core system).
You say it didn't work on your Hero, but were there any errors in dmesg or you didn't find any significant change in speed?
Click to expand...
Click to collapse
dmesg should no difference. the script just showed a lot of errors.
I tried the "non-Ubuntu" version as described in Webupd8, but still similar errors.
I guess Android place the kernel differently from Linux desktops.

I might be mistaken, but SO kernel uses its. And haven't really noticed any difference with or without it.

MaXo64 said:
this patch will be officially introduced in the 2.6.38 kernel..
also, this kernel will have about 50% more speed increase, due to the 200 lines patch and another issue resolved after it .. in general the upcoming kernel will be blazingly fast !!
there is a script that tries to do the same as the patch for earlier kernels. which I use on my Ubuntu laptop, and yes major performance increase !!
I tried to apply it to my previous phone (HTC Hero), but didn't work. I also asked Cyanogen on his twitter, but didn't care to give me an answer..
finally I gave up, and decided to wait for the next Android version that will have the 2.6.38 in the future..
Click to expand...
Click to collapse
please don't spread incorrect facts:
* the "automated per tty task groups" (or autogroup) patch - by using cgroups (in CFS - the cpu scheduler) and thus isolating several taks from each other, giving them dedicated slices of cpu power - allows the system to be more responsive under load if there is a kind of cpu hog (task producing much load)
* the speed increase is due to Nick Piggin's VFS changes and Andrea Arcangeli & Mel Gorman's Transparent Hugepages (THP) support (and of course lots of other changes)
dupel said:
I might be mistaken, but SO kernel uses its. And haven't really noticed any difference with or without it.
Click to expand...
Click to collapse
that's correct: - "sched patch : automated per tty task groups (system more smooth and responsive) (v3(since 4_3) and v4(since 4_4))"
so you tried SO kernel with the patch applied and once reverted ?
but - yeah, I got you: I'm myself running a heavy patched 2.6.37 kernel with transparent hugepages, CFS autogroup, etc. enabled - and it certainly can play off its advantage most noticably during heavy system load

zacharias.maladroit said:
that's correct: - "sched patch : automated per tty task groups (system more smooth and responsive) (v3(since 4_3) and v4(since 4_4))"
so you tried SO kernel with the patch applied and once reverted ?
but - yeah, I got you: I'm myself running a heavy patched 2.6.37 kernel with transparent hugepages, CFS autogroup, etc. enabled - and it certainly can play off its advantage most noticably during heavy system load
Click to expand...
Click to collapse
So, please, correct my noobiness, isn't Android using TTY shells? If it's not than I understand why this patch can't be applied, but if it is, rebuilding a kernel with just 200 lines more is no big deal and we all could benefit from it. It's not very common for Android to be under heavy load but hey, it's going to be default in 2.6.38, so why not?

There is a better patch :
blog.internetnews.com/skerner/2010/11/forget-200-lines-red-hat-speed.html
But I don't know if android uses shells.

Protocamlann said:
There is a better patch :
blog.internetnews.com/skerner/2010/11/forget-200-lines-red-hat-speed.html
But I don't know if android uses shells.
Click to expand...
Click to collapse
Yes, that's exactly the script I was talking about a few posts ago. On my system running 2.6.35, I did not rebuild the kernel with the "patch of wonders" but applied this script. But as you may have read, it acts in userspace which is slightly different in Android (as far as I know it's not using the same environment variables and I don't know about any ~/.bashrc equivalents, but again correct me if I'm wrong), that's why a kernel-oriented patch would be more suitable.

* well, actually newer revisions of that patch don't make use of ttys but of the task session
so basically it seems to create separate groups for each task (or program for simplicity's sake)
(source)
I'm also not sure if current Android kernel revisions use CFS at all ("Android versus Linux?")
laststufo has the autogroup patch included in his SO Kernel but I don't know how to measure its effect ... (whether it makes any difference)
* other options to improve interactivity would be to use Lennart Poettering's bash-approach (the script), like MaXo64 already posted: link
since Android uses Bourne Shell (sh) instead of BASH the script might need to be rewritten
* if it's stable enough on the SGS - yet another option would be to use Con Kolivas BFS

thunderteaser said:
Yes, that's exactly the script I was talking about a few posts ago. On my system running 2.6.35, I did not rebuild the kernel with the "patch of wonders" but applied this script. But as you may have read, it acts in userspace which is slightly different in Android (as far as I know it's not using the same environment variables and I don't know about any ~/.bashrc equivalents, but again correct me if I'm wrong), that's why a kernel-oriented patch would be more suitable.
Click to expand...
Click to collapse
well, you could rewrite that script that it is run as a init-script (afaik in /system/init.d/ )
besides that:
there are stripped down (smaller) versions of bash 4.1* that are known to work on CM6 and the HTC Hero
so it should be a possibility to use that script on stock roms, too
if you can install busybox & root it, there also should be the possibility to install bash

zacharias.maladroit said:
* well, actually newer revisions of that patch don't make use of ttys but of the task session
so basically it seems to create separate groups for each task (or program for simplicity's sake)
(source)
I'm also not sure if current Android kernel revisions use CFS at all ("Android versus Linux?")
laststufo has the autogroup patch included in his SO Kernel but I don't know how to measure its effect ... (whether it makes any difference)
* other options to improve interactivity would be to use Lennart Poettering's bash-approach (the script), like MaXo64 already posted: link
since Android uses Bourne Shell (sh) instead of BASH the script might need to be rewritten
* if it's stable enough on the SGS - yet another option would be to use Con Kolivas BFS
Click to expand...
Click to collapse
It seems you're very well informed, so thanks for the infos you're posting!
I'm not a coder, though, so I hope a kernel developer could pick this up and go for BFS. You said laststufo already implemented this patch in his kernel, so that's really good! We should just find a way of testing its effectiveness.
zacharias.maladroit said:
well, you could rewrite that script that it is run as a init-script (afaik in /system/init.d/ )
besides that:
there are stripped down (smaller) versions of bash 4.1* that are known to work on CM6 and the HTC Hero
so it should be a possibility to use that script on stock roms, too
if you can install busybox & root it, there also should be the possibility to install bash
Click to expand...
Click to collapse
Yes, I've also seen bash shipping with some ROMs, so it's definitely possibile, though as I said before, I'm no coder...

thunderteaser said:
It seems you're very well informed, so thanks for the infos you're posting!
I'm not a coder, though, so I hope a kernel developer could pick this up and go for BFS. You said laststufo already implemented this patch in his kernel, so that's really good! We should just find a way of testing its effectiveness.
Click to expand...
Click to collapse
I'm a kernel-dev for linux-kernels so I got to know & learned to cherish them
just stumbled over a thread in the Epic 4G forum
for reference: [Q] [REQ] Galbraith Patch worked into kernals?

zacharias.maladroit said:
I'm a kernel-dev for linux-kernels so I got to know & learned to cherish them
Click to expand...
Click to collapse
You really are? That's great! So why don't you join laststufo to try maximizing the impact of his implemented "patch of wonders"? As I try to keep up with your techical chatting it seems I really can't do more than asking you to help!
zacharias.maladroit said:
just stumbled over a thread in the Epic 4G forum
for reference: [Q] [REQ] Galbraith Patch worked into kernals?
Click to expand...
Click to collapse
Uhm, so it seems BFS isn't stable on our hardware, pretty bad.

Related

[REF][SCRIPTS] Android Optimization Tips - Vibrant (UPDATED 10/19/2011)

Introduction
I've made a Definite Guide on Android thread for i9000 that focuses on a few optimizations/scripts I've picked up over the months I've spent on XDA. I truly enjoyed sharing my knowledge with the i9000 community and since the tips/guide/scripts can also be applied here (save some exceptions that I would list down below),I would like to share this with the Captivate community too.
Exceptions
Take note that the guide is primarily for i9000 units. There are a few differences I can note here that you should be aware of:
1. The guide points out some kernels/ROMs that are for i9000. Hence the phones you are using may have different ROMs/kernels that may or may not correlate with the one in the guide.
2. The guide also mentions some apps/tweaks that are particularly alien to your unit and you may have never encountered it in your use of your phone or in XDA. Please ignore them for now, I'll make an effort to make the guide compatible in the future (with feedback from you guys of course )
3. Journaling scripts that are attached like the JournalingOn.zip and Acid Tweaks - Removed Useless Stuff and 00remount may not work well with your unit or it may completely brick it. I don't know this, but if you can post your mount partition configuration, I am willing to make the scripts work for you. You only have to type "mount" on your Terminal Emulator and provide the output to me, and I'll provide the rest. Zach's script however, have high compatibility towards a lot of phones, and thus can be used for your unit. Take note that there is a slight risk that it won't work well. If it doesn't, please post your problems here, and I'll try to fix it. Hence, it's best that you make a nandroid backup before attempting to use any tweaks here.
3. I've compiled a guide on a few notable tweaks in XDA here: LINK. If you would like me to evaluate scripts/tweaks/anything that you do not understand due to their terms being alien to you, I'll be glad to explain it here
Guide
You can refer to the guide here:
LINK
s98screenstate_scaling script (provided in attachment) works for any kernel ?
and thanks, for good stuff.
neobuddy89 said:
s98screenstate_scaling script (provided in attachment) works for any kernel ?
and thanks, for good stuff.
Click to expand...
Click to collapse
Yes, it should work if your kernel has conservative as well as ondemand governor implemented in the kernel, and the kernel supports init.d scripts.
If your kernel doesn't, you can edit the script and point to a governor of your liking. Instructions are in the script itself.
Would it be possible to use scary as sleep and smartass for awake? I'm using the dragonmodz kernel listed here http://forum.xda-developers.com/showthread.php?t=1049894 I tried to make the edits myself but just end up freezing my phone.
G00DFe77a said:
Would it be possible to use scary as sleep and smartass for awake? I'm using the dragonmodz kernel listed here http://forum.xda-developers.com/showthread.php?t=1049894 I tried to make the edits myself but just end up freezing my phone.
Click to expand...
Click to collapse
Yes, it's possible. However, the thresholds and other settings for it needs to be overwritten with scary/smartass default settings as the ones in there are default for conservative and ondemand respectively.
Made some pretty big changes to the guide.
Please refer to it when you have the time!

[MOD][CM7] Patched libsqlite.so

I shared before a patched libsqlite.so for froyo and now I bring you CM7's one.
Advantages: Faster I/O operations (applications will open/close faster; quadrant I/O will be higher; ...)
Download: http://dl.dropbox.com/u/13427114/patched-libsql-CM7-p970.zip
Instructions: Just copy to microSD card and flash on CWM like you usually do. No wipes needed.
I may not have a Black anymore but I still want to see my favorite community spoiled with goodies!
P.S. Needs to be reflashed after each nightly/version.
thanks !!!
And this is the reason why Nova will always have a special place in our hearts xD
Trying, thx knzo for all your support to this community!
Enviado desde mi LG-P970 usando Tapatalk
can't you push this to cm7's repo, so it would be build-ed every nightly?
and...thank you for ur work
johnnyslt said:
can't you push this to cm7's repo, so it would be build-ed every nightly?
and...thank you for ur work
Click to expand...
Click to collapse
Nay, you'll have to reflash it after every nightly.
I included this information on the first post.
works great THANK YOU
knzo said:
I may not have a Black anymore but I still want to see my favorite community spoiled with goodies!
Click to expand...
Click to collapse
Thanks a lot. You already owe us with nova. And we are happy to owe you more!
Do you have the source... or I have to surf a bit?
http://forum.xda-developers.com/showthread.php?t=903507
You are the man!
I'm using the libsqlite.so from your Knzo kernel. Is this the same or there are some more tweaks? Regards..
thx dude,i think it's also available for v20a
Thanks a lot!
However, could it be used to our android 2.2 STOCK ROM??
big thanks for this great job
Is this file device specific to p970? Can I possibly use it on my CM7 Nook Color which uses the OMAP3610 processor?
thank you knzo, you have really done a lot! And i deeply appreciate your work.
This really work? This make things faster?
Yeah, no problem on me. That is increase i/o performance, better than v20n stock rom..
Sent from my LG-P970
Hi guys,
According to one polish android fan he went into troubles using this patch (data integrity issue - phone lagging, maildroid issues), so be careful using this and pay attention to ownhere's statement:
ownhere said:
WARN:The following steps only for developers. The following changes may cause instability or even cause the phone can not be used.
Android phones as the underlying database using sqlite3. sqlite3 writes efficiency is very low, because the sync feature turned on by default, and fsync() must be performed after each insertion, the resulting system efficiency is low, and the disk life is reduced.
I try to disable sync feature by default in exchange for greater IO performance and reduce disk consumption. While doing so may result in data integrity problems, but I still like to use it because most of the sqlite insert action can be completed within a few seconds, not too much to consider issues such as sudden power-down.
After modified, the time of insert 2000 records to sqlite3 db, from 1m11s reduce to 2s.
Attachment is my sqlite3 patch, it is for CM or AOSP.
For SenseROM, I can not simply replace libsqlite.so from AOSP, so I do hexedit with it.Do follow modify for SenseROM libsqlite.so:
...
Click to expand...
Click to collapse

[DEV][KERNEL] 3.x for CM10

Goal: kickstart 3.x custom kernel development.
Changelog:
Built with Google's 4.6 toolchain (* see notes).
Merged Interactive from mainline and enabled input boost by default as part of Google's Project Butter. Interactive will be the only available governor as it's Jellybean's "official" governor and having more selection only slows down the kenel. Interactive will provide more smoothness, especially with input boost enabled, but it may be slightly more expense on the energy consumption (significantly? maybe).
The I/O scheduler is deadline with the fifo batch reduced to 1. For smartphones the best I/O schedulers are often the simpler ones and that means deadline, simple or noop. However, for these 2 years deadline keeps providing me the best results, at least in single-cores. Noop is also available. And yes, I know about the new BFQv4 and all the tweaks/heuristics for flash devices, it's still crap.
Switched the slab allocator to slub with a decreased max_slab_order (Andrea Righi) in order to reduce overhead.
Glibc versions for memcopy and memmove, improved CRC32 and RWSEM algorithms, Tiny Shmem implementation, etc.
Changed RCU to Tiny Preempt without RCU boost, some config cleanups and debug removal (like frame pointer) and so on.
... more changes can be seen in: https://github.com/knzy/lge-kernel-sniper/commits/android-omap3-3.0
A few notes: BCM4329's PM_FAST is already enabled by LGE. I also didn't merge many mainline updates as like it has already found out this often hurts performance and decreases stability. Furthermore, you may notice that there aren't many modifications to the kernel but this is because most patches out there are bull**** and rely on placebo effect. Even some changes I did will have a doubtful influence in the kernel. Oh, one more thing, it's possible to build it with Linaro 4.7 toolchain (it needs a few fixes in Makefile though) but it's less stable and not that much faster.
Download: There'll be no available flashable zips. Just build the kernel if you want and use Aprold's kernel injector package.
Now, any kernel posted in XDA must be GPL compliant which means sharing the source, the config file and the toolchain used. I will now shortly describe how you can build the kernel in a linux (ubuntu-based) machine (by the way, if you see anyone sharing a kernel without providing source, config or toolchain, tell me and I'll report them):
Code:
git clone git://github.com/knzy/lge-kernel-sniper.git ## default branch is omap3-3.0 already
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6 ## Add -b master if building on 64-bit
cd lge-kernel-sniper
make ARCH=arm knzo_p970_defconfig
make ARCH=arm CROSS_COMPILE=../arm-eabi-4.6/bin/arm-eabi-
The kernel will be at arch/arm/boot (zImage), use it with Aprold's kernel injector package and voilá.
Awesome Welcome back
koila33 said:
Awesome Welcome back
Click to expand...
Click to collapse
Oh, it's just for fun and to keep aprold busy.
Make sure to add git://github.com/CyanogenMod/lge-kernel-sniper.git as upstream and keep it updated.
Ah, don't disable KSM as I did in my first test release as P970 will probably struggle for RAM in JB.
As for my repo/changes, feel free to fork, test, retest, revert, whatever.
How to use?
Sent from my Nexus 7 using xda app-developers app
wskyvwsk said:
How to use?
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
Reading couple of lines is too hard for you, eh? You didnt found link to download and just replayed to thread thoughtlessy?
performance test ?
Cedlad said:
performance test ?
Click to expand...
Click to collapse
Benchmarks are so Gingerbread, we don't use that anymore. The most faithful benchmark is everyday's usage.
Done, i have made a new boot.img with your mofifications.
Lets see.
knzo said:
Benchmarks are so Gingerbread, we don't use that anymore. The most faithful benchmark is everyday's usage.
Click to expand...
Click to collapse
But CM10 Kernel is so Bad.. :/ i want to see if there is a better one ..
Cedlad said:
But CM10 Kernel is so Bad.. :/ i want to see if there is a better one ..
Click to expand...
Click to collapse
Yeah, Aprold told me CM10 was still a bit sluggish but I'm not sure it's the kernel fault. Give rmcc some time to iron out the port.
Already tried the kernel and everthing works fluid and fast, i have an issue with wi-fi but that can be fixed easly Good job.
waiting
Nice post knzo
Wow. Good see you again here in XDA.
Welcome hack, knzo.. Nice to see you again at P970 forum
Code:
PS: I'm not typo "back" with "hack" :p
redy2006 said:
Welcome hack, knzo.. Nice to see you again at P970 forum
Code:
PS: I'm not typo "back" with "hack" :p
Click to expand...
Click to collapse
where is the kernel's flashable zip
aasimkhan30 said:
where is the kernel's flashable zip
Click to expand...
Click to collapse
*facepalm*just show that you can't read
Hi guys, I'm going to try build this kernel, just for fun.
It will be my second attempt on building a kernel, my first try didnt work like it should...I wonder why
I'm more into Windows Servers/AD/TCPIP and that kind of stuff and very basic skills on linux.
Can I count on your help?
ontour said:
Can I count on your help?
Click to expand...
Click to collapse
Yeah of course but it's actually quite simple.
Just grab virtualbox and an ubuntu image, install it then open a terminal and do the commands I posted.
As for all the others asking for a flashable zip: no, crackflashers and average users, this thread is not for you. This is for developers, pseudo-developers, enthusiasts and oldschool users who are here to learn, not for those who are here because they think they are entitled to the service of after-market customization.
knzo said:
Yeah of course but it's actually quite simple.
Just grab virtualbox and an ubuntu image, install it then open a terminal and do the commands I posted.
As for all the others asking for a flashable zip: no, crackflashers and average users, this thread is not for you. This is for developers, pseudo-developers, enthusiasts and oldschool users who are here to learn, not for those who are here because they think they are entitled to the service of after-market customization.
Click to expand...
Click to collapse
Hahaha you cant even imagine, how much I like this post Nice to see you back here Do you already have got a P970 again?
Thanks for sharing

[KERNEL][L][STOCK][5.1]intersectRaven's Kernel - 20150524_05XX

Development Goals:
- stability
- energy savings due to more efficient ARM algorithms
- strictly no overclocking unless approved by the manufacturer or my source base integrates it (also, even if my source base integrates it, expect no support for it)
- no undervolting as well unless the manufacturer approves it since it's relatively pointless IMHO...
- all improvements should require MINIMAL user interaction (e.g. you don't need to do anything except flash the kernel or at the very least use SetCPU or the like to set fixed options)
- stability
*note: FAQ is at the 3rd post
Latest Kernel Here
Boot-B -> LBY29G
Boot-O -> LMY47O PH
Boot-M -> LMY47O India
OR
Boot-Universal -> custom recovery flashable zip for all ROMs (I hope :fingers-crossed
*there are significant ramdisk differences between PH and India versions which is weird
20150524_05XX:
- missed something in the previous commit
*this is why I don't like developing kernels on devices I don't use or stopped using actively :/
20150523_21XX:
- implemented minor config changes and a better fix for kernel ooops upon changing CPU governors
20150509_11XX:
- modified proportional frequency allocation algorithm to prefer minimum frequency more
20150503_17XX:
- improved power efficiency of entire kernel
20150426_09XX:
- optimized frequency scaling algorithm to minimize scaling to max during hotplug and under certain situations
20150423_22XX:
- ported one of my Kindle Fire modification which I just remembered could impact performance extremely well
20150417_14XX:
- reverted RCU patch mistakenly committed without dependency which caused RCU slowdown
20150412_20XX:
- numerous backports from linux 4.0 for timer, scheduler and ARM
20150411_21XX:
- numerous backports from linux 4.0 for timer, mutex and slub functionality performance improvements
20150411_18XX:
- kernel tweaks from imoseyon
20150410_17XX:
- timer optimization
20150409_17XX:
- disabled dithering since I think hardware doesn't need it (please report any sign of image degradation)
- now also in flashable zip form (please test as I don't have custom recovery)
20150408_23XX:
- merged Motorola's lowmemorykiller tree improvement
- applied latest ondemand patches to hotplug to improve frequency selection
20150407_14XX:
- recoded some MediaTek modifications with more optimal instructions
- removed more unnecessary kernel options
20150405_19XX:
- removed touch boost as it seems to be unnecessary
- removed some useless logging entries
- adjusted some code that prevented the frequency from being ramped down immediately
20150405_10XX:
- changed default IO scheduler to ROW imported from Lenok source with additional commits due to MediaTek changes
- modified readahead value to 512KB
20150403_16XX:
- bug fix due to incorrect scoping of the touch frequency modification causing excessive use of 747Mhz
20150402_06XX:
- integrated Mali commits by varun
- some minor optimizations
20150331_22XX:
- modified hotplug governor to use ondemand algorithm
- hotplugging now doesn't raise frequency to max before doing a hotplug operation
- touch boost frequency now set to 747Mhz instead of max to lower power consumption
20150329_16XX:
- finished porting all relevant commits from Lenok source to Sprout
- initial full release
- significant changes include:
enabling of full tickless mode
modification of some kernel libraries to use optimized ARM instructions
Disclaimer:
Flash at your own risk.
You can find my other kernels at:
http://intersectraven.euroskank.com/kernels
GitHub is at:
intersectRaven's GitHub
XDA:DevDB Information
intersectRaven's Android One Kernel, Kernel for the OEM Cross Device Development
Contributors
intersectRaven
Kernel Special Features:
Version Information
Status: Testing
Created 2015-04-03
Last Updated 2015-04-02
Special Thanks To:
DooMLoRD - some patches I integrated are from his repo
faux123 - some patches I integrated are from his repo
arter97 - some patches I integrated are from his repo
varun - Mali patches are from his repo and his generic kernel implementation
Other devs I neglected to mention.
FAQ:
1.) How do I flash this on my device?
You could use fastboot, flashify, or flash through recovery using the provided recovery flashable zips.
2.) How do I return to stock kernel?
Use the "fastboot flash boot" command using the stock boot image I provided in another thread here.
3.) Will you be releasing frequent updates?
Right now I don't see anything else needed to improve this kernel as I am quite satisfied with it. You could post suggestions BUT they must have MINIMAL USER INTERACTION or will only seek to enable editing of certain values.
4.) How do you verify that it flashed correctly?
Well, if it booted after fastboot showed the "writing" dialog, then it should be ok already. If you're ultra paranoid that maybe fastboot is lying to you or the NSA doesn't want you to know that it didn't overwrite the stock kernel which contains their secret spy stuff that wants to know how frequently you exercise you could enter the ff. command through adb:
cat /proc/version
and the kernel should show #7 and intersectRaven there together with the date that the kernel was compiled which is what I use to indicate the release.
Reserved 3
which is better thunderzap or yours? thanks
Androidoo said:
which is better thunderzap or yours? thanks
Click to expand...
Click to collapse
I guess it's not right to compare both kernel. Both are awesome, but this kernel are optimized for stock, while ThunderZap are optimized for both CM12.1 and stock.
Will this improve battery life
Sent from my Android One using XDA Free mobile app
Kohul Raj said:
Will this improve battery life
Sent from my Android One using XDA Free mobile app
Click to expand...
Click to collapse
Yes, depends on your usage. I notice a bit of increase in battery life, but that's all depends on your usage.
F4uzan said:
Yes, depends on your usage. I notice a bit of increase in battery life, but that's all depends on your usage.
Click to expand...
Click to collapse
Interesting. What version are you using currently? 20150402_06XX? Can you use the one after that (or the latest one released today) and observe battery life with your typical usage? Might be the bug I introduced due to an improper understanding of what a line was doing.
intersectRaven said:
Interesting. What version are you using currently? 20150402_06XX? Can you use the one after that (or the latest one released today) and observe battery life with your typical usage? Might be the bug I introduced due to an improper understanding of what a line was doing.
Click to expand...
Click to collapse
Sure, I'll try Gotta backup and reflash stock then.
-EDIT : I have flashed it, I'll test it for two days and I'll report the results
F4uzan said:
Sure, I'll try Gotta backup and reflash stock then.
-EDIT : I have flashed it, I'll test it for two days and I'll report the results
Click to expand...
Click to collapse
Thanks! You didn't have to if you're not on stock already so I appreciate it!
I'm happy because android one development is growing now
By the way, i'm in thunderzap kernel, can i flash this directly? or i have to go back to stock kernel then flash this? Thanks..
yonzz said:
I'm happy because android one development is growing now
By the way, i'm in thunderzap kernel, can i flash this directly? or i have to go back to stock kernel then flash this? Thanks..
Click to expand...
Click to collapse
This is for stock ROMs. Doesn't matter if you're using a different kernel, what's important is you're not on CM or any non-AOSP based ROM.
anyone can report the result please ? ?
Sent from my MITO_A10 using xda Forum
mrahmanda said:
anyone can report the result please ?
Sent from my MITO_A10 using xda Forum
Click to expand...
Click to collapse
I have used it for a day, there is a slight improvement in battery life.
Can you add USB OTG support and double tap to wake
stuck after android logo... using O for LBY ... build number LBY25G
acus123 said:
stuck after android logo... using O for LBY ... build number LBY25G
Click to expand...
Click to collapse
That's odd. Did you flash anything else before or is this pure stock Cherry Mobile One?
Way better than stock kernel. Performance has improved and battery drains slowly(Compared to stock kernel). I would prefer this kernel over stock anytime!
Regards.
PS: I would request the developer to make a flashable ZIP next time or can provide as an additional package because it's a bit inconvenient to open up PC and flash via ADB. Anyway, a great work!
I've tested the kernel extensively over few days and I can confirm battery improvements

[MODS DELETE THIS THREAD] exNoShadez-eas

Mod edit: Thread closed on owner's request!
exNoShadez-EAS Kernel
FEATURES
- Current LTS release -> Linux-3.18.114
- Energy Aware Scheduling
- Schedutil (default Cpu Governor)
- RCU infrastructure backport (with expert mode enabled)
- Cpu-Boost / Input Boosting (enabled by default)
- BINFMT_MISC support (NOT mounted on boot).
- Kernel Hardening/Protection (CopperheadOS/Grsec/Pax Marlin kernel hardening features)
- leds-qpnp: Notification LED control - V1.1c (Boeffla) - Adapted for Marlin
- Binder_rt = My own re-implementation of AOSP Binder that uses rt_mutexes; supporting priority inheritance
- Improved scheduling/determinism for high priority threads/tasks
- Backported Scheduling, Locking and Workqueue subsystem code from Newer Linux kernels.
- Audio Driver enhancements / backports (from Wahoo/Pixel 2)
- Sound/Audio driver Tweaks (bug fixes, scheduling improvements)
- forced Interrupt threading enabled
- Wifi Mac Address Randomization
- WireGuard VPN kernel module support (more info soon)
- KCal Advanced Colour control
- Improved ASLR (in kernel)
- USB Fast Charge
- Wake Gestures
- GCC 6/7+ Fixes
- Built with GCC-8.x-dev
- and more
Contains code from everywhere: Code Aurora, Flar2/Marlin, CopperheadOS, AOSP, Project-EAS, Freak7/Kirisakura, Linaro, Pixel 2 kernel sources, mainline linux and elsewhere. Modifications and backports by me, as well.
BACKGROUND
I wanted a kernel for My Pixel that had 'all of the things', it didn't exist... So I'm working on my own kernel. I try to balance Security/hardening, experimental features with high Performance and battery life. <- not an easy task! ... Some of the security features do come with overhead, but if you use apps that are CPU heavy / processing and/or require low latency - they will perform well (at the cost of chewing some battery life, of course).... Battery life and SOT are very reasonable though.
WARNING / VERY IMPORTANT: This kernel isn't compatible with installing TWRP ~> meaning; you must use the fastboot version of TWRP (used in RAM) , flash the kernel and NOT install TWRP to your system (the kernel is too big for TWRP to co-exist).... This may sound inconvenient, but there are a number of valid reasons to avoid reducing a kernel's size in order to support TWRP installation, in the boot partition.
***Fun facts on this subject below => in the 2nd post: PLEASE READ: to understand my motivation***
TWRP REMOVAL
*To remove TWRP from your system; You need the stock boot.img from your running/current firmware (which is inside of the factory image zips) or use the Nov Stock boot.img provided here. Then it's as simple as flashing the boot.img to wipe TWRP;
fastboot flash boot_a /path/to/boot.img
fastboot flash boot_b /path/to/boot.img
Stock 8.1 July 2018 Boot.img => https://github.com/nine7nine/Apps/raw/master/SailfishStockJulyBoot.img
Now you can proceed with using the TWRP fastboot boot.img to flash my kernel, magisk/supersu or whatever else....
Fastboot twrp boot image => https://dl.twrp.me/sailfish/twrp-3.2.2-0-sailfish.img
WARNING: This shouldn't need to be said, but we did have someone who did this, so I'm adding a sticky/warning here; do NOT EVER re-lock your bootloader after flashing any kind of custom software, kernels, etc to your device - *it will brick your phone*. Meaning you are screwed would need an RMA / replacement device ... everyone in the XDA community should know better, but still; worth mentioning....
IMPORTANT:
Before asking questions; Please read through the thread (starting with the last few pages) - I shouldn't need to be repeatedly answering the same questions over and over again. It's good practice to get into the habit of reading through threads before asking questions in any thread on XDA, as more often then not; you're question has probably been answered. Thanks!
EXNS-EAS KERNEL DOWNLOAD:
JULY 2018 OREO 8.1 RELEASE exNoShades-eas Kernel Flashable zip
https://github.com/nine7nine/Apps/raw/master/exNoShadez_eas_v2.8.2_f94351f.zip
It is stable, high performance and very responsive...
Important: You will need root; I don't support non-rooted devices && some features require it. I recommend using Magisk; https://forum.xda-developers.com/apps/magisk/beta-magisk-v13-0-0980cb6-t3618589 ...
NOTE: Make sure to flash the latest Magisk beta *before* flashing the kernel zip. ...
More Background / Important Notes:
Binder_RT:
My own port and re-implementation of the Binder Kernel Driver; a slightly modified version of The AOSP binder.
Binder_RT uses rt_mutexes as opposed to mutexes for locking in Binder, ion, ashmem, etc... rt_mutexes support priority inheritance and should improve determinism in Binder, speed up IPC, Ion and Ashmem => Allowing applications that require low-latency, tight deadlines, low jitter and deterministic behaviour to perform better ~ This re-implementation is proving to be the great for those types of applications. The goal here is to help ensure that the Kernel and Binder's high priority && time critical threads and tasks are properly prioritized... Example; audio buffers arriving on time / no buffer underruns... *Further development work is planned to research, experiment with and improve Binder_RT.
rt_mutex documentation, for those interested;
https://github.com/nine7nine/Marlin_exns-eas/blob/EXNS_EAS/Documentation/locking/rt-mutex.txt
https://github.com/nine7nine/Marlin_exns-eas/blob/EXNS_EAS/Documentation/locking/rt-mutex-design.txt
CPU-Boost / Input Boosting:
Touch inputs boost CPU frequencies (thus improves performance and responsiveness).
# Cpu-boot / Input boost settings
write /sys/module/cpu_boost/parameters/input_boost_enabled 1
write /sys/module/cpu_boost/parameters/input_boost_freq "0:1363200 1:0 2:1900800 3:0"
write /sys/module/cpu_boost/parameters/input_boost_ms 100
IO/ CPU Governors:
This kernel doesn't include a thousand io/cpu governors. IO-wise; CFQ is the default, but we've got a few in there. chose your poison, but know that the majority of my testing is centered around cfq and deadline. CPU Governor-wise the common Linux CPU governors are there; along with Sched and Schedutil....
Stick with Schedutil - on idle, it draws very little power and in most 'peak performance situations, it should do very well..... I'm getting great battery life, sot and performance.
Managing Kernel Settings:
Get EX Kernel Manager - my original code on github was forked from EX kernel, before rebasing it - but EXKM will give you access to 99% of my kernel's settings.
My 8.1 Kernel Sources: https://github.com/nine7nine/Marlin_exns-eas
Donations via PayPal very much appreciated. I do put a significant amount of energy and time into researching, development, testing / QA and also providing support/help to end-users... It's definitely not mandatory to donate; but If you appreciate the effort, see value or benefits from using my kernel on your device and can afford to; Use the "Donate to me" button or the below link... It makes a big difference. thanks!
https://www.paypal.me/jrdnjhnstn
Why TWRP Installations are NOT supported:
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
(and why I'm not using it!)
Most custom/android kernel devs are using the above configuration in kernel compilation, which is arguably very BAD... I understand that boot partitions are small and the desire to install TWRP to them, thus there is a need to reduce the kernel's size....and yes, this will achieve that - However;
1. SUSE, RedHat, etc (Enterprise linux) disable CONFIG_CC_OPTIMIZE_FOR_SIZE -> it's original use case has proven to be invalid. Even Google (in their own documentation) advise against using this; https://source.android.com/devices/tech/perf/boot-times ....
2. It suppresses useful compiler warnings....
3. As SOCs have become more powerful, google has come to the same conclusion that Enterprise Linux did back in 2012.
4. by turning off CONFIG_CC_OPTIMIZE_FOR_SIZE, we achieve better performance, boot time and better cache utilization.
Clark Williams / Redhat Bugzilla said:
* Cause: CONFIG_CC_OPTIMIZE_FOR_SIZE set with assumption that smaller code would yield hot cache lines and good performance
* Consequence: this config caused gcc to generate jump-to-jump code which causes cache line bouncing, hurting performance
* Fix: turn off CONFIG_CC_OPTIMIZE_FOR_SIZE
* Result:slightly larger kernel but better cache utilization
Click to expand...
Click to collapse
(The Above is quoted from Clark Williams, A Senior Software Architect @ RedHat -> https://bugzilla.redhat.com/show_bug.cgi?id=796297)
I know of no other way to significantly reduce kernel size. Disabling some debugging, unneeded features, etc helps - but not enough.... I am focusing on optimization, using newer builds of GCC/Linaro, performance enhancements, fixing compilation errors, etc, etc -> these things are more important than trying to support TWRP installation. Therefore; I do NOT support installing TWRP....
I like it so far, very good kernel.
Awesome! Always nice to have choices
I've seen you post around that you made x change to your own kernel, glad you finally made it public!
Does it have all of franco's wakelocks blocked by default?
グリッチ said:
Awesome! Always nice to have choices
I've seen you post around that you made x change to your own kernel, glad you finally made it public!
Does it have all of franco's wakelocks blocked by default?
Click to expand...
Click to collapse
hey, it includes franco's wakelocks stuff. I don't think all are blocked, I actually don't touch them in my init rc. ... but some are blocked by default, for sure. can be set by user...
yeah, I've got my kernel to a point now, where it is somewhat unique && is drawing in most of the best features from every custom kernel for the pixel (my opinion). very stable too, thus far. so makes sense to make it public.
it's got the RCU (read copy update) infrastructure from linux-4.9... a ton of core, sched, Walt, etc from linux-4.4+ (specifically, from EAS-Project / msm8998 OP5 - which was painful to backport. wish we didn't have a 3.18 kernel. lol) afaik, it's the only Marlin kernel with Dynamic Stune Boost and aside from CopperheadOS; the only marlin kernel with a subset of the PAX/grsec kernel security enhancements and the Mac randomization... also has all of the audio enhancements from the kernel ur running ?
siheals said:
I like it so far, very good kernel.
Click to expand...
Click to collapse
Hey! thanks for testing it out. let me know how things go, your impressions, etc.
I'll be updating this kernel constantly, so if u end up liking it; you can expect that it will always include security patches, linux LTS incremental patches, etc...
it's my daily driver, so i keep on top of it.
Superb! Thanks for clarifying.
I will give it a run when November update releases cuz I'm lazy >.< but am excited and looking forward to it ^_^
グリッチ said:
Superb! Thanks for clarifying.
I will give it a run when November update releases cuz I'm lazy >.< but am excited and looking forward to it ^_^
Click to expand...
Click to collapse
no probz. As soon as the november updates arrive, i will be adding whatever patches are needed... so expect that to be there...
i also pull from Code Aurora msm-3.18 for 8996, so my kernel gets updates to drivers, core, etc that google hasn't picked up yet.
Just Testing 3.18.79 + latest Code Aurura updates for today ....AND;
re-enabling a hardening feature that I thought was draining battery life (Likely not, was probably another removed patch - that isn't in the current release.)
I'll update the link later on and - on my github; where I link to for downloads; there will be older releases labeled - ie:
exNoShadez_eas.zip (current release / link) will become -> exNoShadez_eas_3.18.78_oct.zip,
when it is replaced by 3.18.79 + other updates / patchwork.... The current release will always be -> exNoShadez_eas.zip
UPDATE:
While I haven't updated exNoShadez_eas.zip link/version, * I have posted a zip with the above changes - I'll be testing it for a while before updating the link because it's hard to gauge battery life without a lot of testing / time spent.... So I would say, if anyone is eager - they can test it, but wait at least 12-24hours from testing the current available release - so you can actually make some sort of real-usage comparision.
link: https://github.com/nine7nine/Apps/raw/master/exNoShadez_eas_3.18.79_harden.zip
Glad to see you have posted this man. Setting up a pixel for my friend and as i was browsing the forums noticed you have a lot of good kernel work. Was literally about to PM you a few days ago for your kernel and then happened to see this post today. Can't wait to try it out!
Warrimonk said:
Glad to see you have posted this man. Setting up a pixel for my friend and as i was browsing the forums noticed you have a lot of good kernel work. Was literally about to PM you a few days ago for your kernel and then happened to see this post today. Can't wait to try it out!
Click to expand...
Click to collapse
All good, man.
It only makes sense that I would share my kernel, when I felt it was ready for that - just keep in mind, that for now - I have marked it as Beta / Testing, as it's pretty new (although, aside from the EAS code / Dynamic Stune Boost - the rest has been thoroughly vetted)....
So yeah, give it a run, let me know how things go! thanks
Unsure if I am doing something wrong or not, but when I try to flash your kernel I get an error stating : "New Image larger than boot partition. Aborting...."
EX Kernel flashed fine. Using TWRP 3.1.1-1
Warrimonk said:
Unsure if I am doing something wrong or not, but when I try to flash your kernel I get an error stating : "New Image larger than boot partition. Aborting...."
EX Kernel flashed fine. Using TWRP RC1.
Click to expand...
Click to collapse
Why aren't you using the newest stable version of TWRP?
RC1 = release candidate 1
afaik, latest release is 3.1.1-1 stable for the pixel.... https://dl.twrp.me/sailfish/
Using an old version might be your issue. Update, then try.
nine7nine said:
Why aren't you using the newest stable version of TWRP?
RC1 = release candidate 1
afaik, latest release is 3.1.1-1 stable for the pixel.... https://dl.twrp.me/sailfish/
Using an old version might be your issue. Update, then try.
Click to expand...
Click to collapse
Apparently I am using TWRP3.1.1-1 . The thread was called RC1 So I mistakenly assumes that was still the current version.
Warrimonk said:
Apparently I am using TWRP3.1.1-1 . The thread was called RC1 So I mistakenly assumes that was still the current version.
Click to expand...
Click to collapse
Can confirm this, I'm on 3.1.1-1 too and got this issue.
I'm running 8.0.0 (OPR3.170623.008, Oct 2017) build.
Keasby said:
Can confirm this, I'm on 3.1.1-1 too and got this issue.
I'm running 8.0.0 (OPR3.170623.008, Oct 2017) build.
Click to expand...
Click to collapse
kk. I'll look into this - I (obviously) do not have this problem..... What firmware images do you use?
I'm on Rogers/Canada, maybe the boot partition is a different size on some firmwares (?)....
I can also look at shrinking the boot.img, which could fix it. My boot.img is slightly bigger than the shipped boot.img and I do have an idea on how to shrink it a bit, you'll have to wait until later on for me to look at it though / not home right now.
nine7nine said:
kk. I'll look into this - I (obviously) do not have this problem..... What firmware images do you use?
I'm on Rogers/Canada, maybe the boot partition is a different size on some firmwares (?)....
I can also look at shrinking the boot.img, which could fix it. My boot.img is slightly bigger than the shipped boot.img and I do have an idea on how to shrink it a bit, you'll have to wait until later on for me to look at it though / not home right now.
Click to expand...
Click to collapse
32MB is the boot image max size AFAIK.
nine7nine said:
kk. I'll look into this - I (obviously) do not have this problem..... What firmware images do you use?
I'm on Rogers/Canada, maybe the boot partition is a different size on some firmwares (?)....
I can also look at shrinking the boot.img, which could fix it. My boot.img is slightly bigger than the shipped boot.img and I do have an idea on how to shrink it a bit, you'll have to wait until later on for me to look at it though / not home right now.
Click to expand...
Click to collapse
Maybe it's caused by the image size. Other custom Kernels are sized bout 13mb.
I'm running the Google Stock Build OPR3.170623.008, October 2017.
Hope you can fix it - TIA!
nine7nine said:
kk. I'll look into this - I (obviously) do not have this problem..... What firmware images do you use?
I'm on Rogers/Canada, maybe the boot partition is a different size on some firmwares (?)....
I can also look at shrinking the boot.img, which could fix it. My boot.img is slightly bigger than the shipped boot.img and I do have an idea on how to shrink it a bit, you'll have to wait until later on for me to look at it though / not home right now.
Click to expand...
Click to collapse
Personally I tried on these 2 firmwares:
sailfish-ota-opr3.170623.008
sailfish-ota-opr6.170623.012
The phone was originally a Project Fi device.. if that matters. Dev which firmware and TWRP are you using?
Warrimonk said:
Personally I tried on these 2 firmwares:
sailfish-ota->>>>opr3.170623.008<<<<<
sailfish-ota-opr6.170623.012
The phone was originally a Project Fi device.. if that matters. Dev which firmware and TWRP are you using?
Click to expand...
Click to collapse
I'm using the latest twrp-3.1.1-1 (but and idk if this makes a difference or not), I only use the twrp fastboot img (Ihave ZERO reason to actually install TWRP on my system).... and also, Others have installed and are using my kernel - so it must be a difference in firmwares / boot partition size (or image size)
Keasby said:
Maybe it's caused by the image size. Other custom Kernels are sized bout 13mb.
I'm running the Google Stock Build >>>>>OPR3.170623.008<<<<<, October 2017.
Click to expand...
Click to collapse
So yeah, I'm using a different build **OPR1.170623.027**, Oct 2017, Fi/Canada.... you both are having problems on >>>>>OPR3.170623.008<<<<< ~> Something is different in that build... If you like (and happen to have that image kicking around, you could send me the boot.img and I'll compare it to mine? later on)
I'm thinking it's not the kernel size, although - I do plan on making the kernel smaller on production builds, by reducing a lot of debugging that really isn't needed on a production build (I already have a defconfig for doing so);

Categories

Resources