http://www.pcworld.com/businesscent...x_kernel_patch_delivers_huge_speed_boost.html
http://forum.xda-developers.com/showthread.php?t=844458
could this be worked into Epic 4G kernels as well?
tyl3rdurden said:
http://www.pcworld.com/businesscent...x_kernel_patch_delivers_huge_speed_boost.html
http://forum.xda-developers.com/showthread.php?t=844458
could this be worked into Epic 4G kernels as well?
Click to expand...
Click to collapse
WOW. I am seriously impressed by your "keeping up with the times" mentality. Good job on noticing this!
So...
"n tests by Galbraith, the patch reportedly produced a drop in the maximum latency of more than 10 times and in the average latency of the desktop by about 60 times. Though the merge window is now closed for the Linux 2.6.37 kernel, the new patch should make it into version 2.6.38."
Along with an Overclocked Froyo kernel (once source is out) this should REALLY improve our experiences.
I mentioned in another thread that I am in talks with Paragon software
http://www.paragon-software.com/exp...ocs/technologies/Paragon_UFSD_for_Android.pdf
for NTFS and HSF access. I think that is is POSSIBLE that this is actually a software patch, although it may need to be placed into the kernel itself as a driver. I promise to update as soon as they get back to me as I just spoke to the devs there yesterday.
Looks like our experience is about to improve dramatically!
Already in IntersectRavens latest kernel and wildmonk's latest beta kernels for nexus one. Check the threads
Click to expand...
Click to collapse
From the other xda thread someone mentioned that some kernels have already implemented. I am sure some of them would be glad to share how it is implemented and how easily it can be done. I know it is different phones/kernels but the idea behind it should be similar.
Dulanic said:
From the other xda thread someone mentioned that some kernels have already implemented. I am sure some of them would be glad to share how it is implemented and how easily it can be done. I know it is different phones/kernels but the idea behind it should be similar.
Click to expand...
Click to collapse
We don't have a source kernel for Froyo yet to do this. Someone correct me if I am wrong please.
Edit: I can't find anything mentioning this patch. If anyone has a link post it. I don't believe this is implemented anywhere yet.
I found the below info here:
http://www.reseize.com/2010/11/linux-kernel-patch-that-does-wonders.html
Below is the video of the Linux desktop when running the kernel and the patch in question was applied but but disabled:
As you can see, the experience when compiling the Linux kernel with so many jobs is rather troubling to the Linux desktop experience. At no point in the video was the 1080p sample video paused, but that was just where the current mainline Linux kernel is at with 2.6.37. There was also some stuttering with glxgears and some responsiveness elsewhere. This is even with all of the Linux 2.6.37 kernel improvements up to today. If recording a video of an older kernel release, the experience is even more horrific! Now let's see what happens when enabling the patch's new scheduler code
It is truly a night and day difference. The 1080p Ogg video now played smoothly a majority of the time when still compiling the Linux kernel with 64 jobs. Glxgears was also better and the window movements and desktop interactivity was far better. When compiling the Linux kernel with 128 jobs or other workloads that apply even greater strain, the results are even more dramatic, but it is not great for a video demonstration; the first video recorded under greater strained made the "before look" appear as like a still photograph.
This could be potentially patched into our Eclair kernel if the changes aren't too intrusive, and by the sounds of it they're not.
The mainline patch was against 2.6.39 kernel however, our froyo kernel will be 2.6.32 and eclair is 2.6.29 - so we're several revisions behind in eclair.
It's definitely interesting, but it's geared toward desktops using the group scheduler - absolutely worth a try if that scheduler works with android easily ( most of the community kernels are using BFS scheduler however )
cicada said:
This could be potentially patched into our Eclair kernel if the changes aren't too intrusive, and by the sounds of it they're not.
The mainline patch was against 2.6.39 kernel however, our froyo kernel will be 2.6.32 and eclair is 2.6.29 - so we're several revisions behind in eclair.
It's definitely interesting, but it's geared toward desktops using the group scheduler - absolutely worth a try if that scheduler works with android easily ( most of the community kernels are using BFS scheduler however )
Click to expand...
Click to collapse
Sniff...
It did sound a little too good to be true. Well, eventually we will get 2.6.38 and that has it built in, if the desktop group scheduler can even be used at all it seems.
but because its in other peoples' kernels cant it be easily ported into ours?
tyl3rdurden said:
but because its in other peoples' kernels cant it be easily ported into ours?
Click to expand...
Click to collapse
It's very possible to patch in. If it's been done before, anyway.
But, because it is based on the .39 kernel, it might be a little buggy. Or a lot buggy. You wanna link me to a kernel that has it and I'll look into it? I probably will wait for Froyo source for at least the .32 kernel.
Here's what Linus himself had to say about the patch:
Yeah. And I have to say that I'm (very happily) surprised by just how small that patch really ends up being, and how it's not intrusive or ugly either.
I'm also very happy with just what it does to interactive performance. Admittedly, my "testcase" is really trivial (reading email in a web-browser, scrolling around a bit, while doing a "make -j64" on the kernel at the same time), but it's a test-case that is very relevant for me. And it is a _huge_ improvement.
It's an improvement for things like smooth scrolling around, but what I found more interesting was how it seems to really make web pages load a lot faster. Maybe it shouldn't have been surprising, but I always associated that with network performance. But there's clearly enough of a CPU load when loading a new web page that if you have a load average of 50+ at the same time, you _will_ be starved for CPU in the loading process, and probably won't get all the http requests out quickly enough.
So I think this is firmly one of those "real improvement" patches. Good job. Group scheduling goes from "useful for some specific server loads" to "that's a killer feature".
Click to expand...
Click to collapse
DevinXtreme said:
It's very possible to patch in. If it's been done before, anyway.
But, because it is based on the .39 kernel, it might be a little buggy. Or a lot buggy. You wanna link me to a kernel that has it and I'll look into it? I probably will wait for Froyo source for at least the .32 kernel.
Click to expand...
Click to collapse
Devin- I agree with waiting until the Froyo source is out for attempting to implement this. I'm not sure that group scheduling is even an option in the Android kernel. But I don't think anyone has done this so I doubt any links are coming your way.
Edit: Found this here- http://groups.google.com/group/android-kernel/browse_thread/thread/f47d9d4f4e6a116a/ab1a8ab42bb0b84a
Android is using the CFS.
They are combine with RT scheduling.
When you playing the audio and video service, paltform change the
scheduling policy and change the schedule prority.
search the platform code
dalvik has policy n proiorty setting code, also framework related with
audio n video
check the init.rc and cutil folder
u need to search the platform after eclair release (Froyo)
cicada said:
( most of the community kernels are using BFS scheduler however )
Click to expand...
Click to collapse
Actually, no Epic kernel uses BFS. It isn't stable on our hardware, and its not worth porting. Android uses CFS by default, and then the CFQ scheduler I think, but most have switched from CFS/CFQ to CFS/BFQ combination. I know mine & Devin's kernels have.
Geniusdog254 said:
Actually, no Epic kernel uses BFS. It isn't stable on our hardware, and its not worth porting. Android uses CFS by default, and then the CFQ scheduler I think, but most have switched from CFS/CFQ to CFS/BFQ combination. I know mine & Devin's kernels have.
Click to expand...
Click to collapse
Ok then, so in your professional opinion is this patch a possibility still?
Enter your search termsSubmit search formWeblkml.org
Subject [RFC/RFT PATCH] sched: automated per tty task groups
From Mike Galbraith <>
Date Tue, 19 Oct 2010 11:16:04 +0200
Greetings,
Comments, suggestions etc highly welcome.
This patch implements an idea from Linus, to automatically create task groups
per tty, to improve desktop interactivity under hefty load such as kbuild. The
feature is enabled from boot by default, The default setting can be changed via
the boot option ttysched=0, and can be can be turned on or off on the fly via
echo [01] > /proc/sys/kernel/sched_tty_sched_enabled.
Link to code: http://forums.opensuse.org/english/...ernel-speed-up-patch-file-mike-galbraith.html
Thanks for the clarification Geniusdog254.
ZenInsight, any chance you can prune down that post and just use a link? The patch is all over the web right now, and it's hard to scroll by on a phone
ZenInsight said:
Ok then, so in your professional opinion is this patch a possibility still?
Click to expand...
Click to collapse
I'm sure its possible, I just haven't looked at it yet. Like I stated before, until we get 2.6.32 FroYo kernel source I'm not doing any devving besides app work (maybe)
EDIT: Devin said on the last page that he'll look into it. I know IntersectRavens Nexus kernel has it, but I haven't looked into any reports of how much it helps.
Also found this:
Phoronix recently published an article regarding a ~200 lines Linux Kernel patch that improves responsiveness under system strain. Well, Lennart Poettering, a RedHat developer replied to Linus Torvalds on a maling list with an alternative to this patch that does the same thing yet all you have to do is run 2 commands and paste 4 lines in your ~/.bashrc file. I know it sounds unbelievable, but apparently someone even ran some tests which prove that Lennart's solution works. Read on!
Lennart explains you have to add this to your ~/.bashrc file (important: this won't work on Ubuntu. See instructions for Ubuntu further down the post!):
CODE:
if [ "$PS1" ] ; then
mkdir -m 0700 /sys/fs/cgroup/cpu/user/$$
echo $$ > /sys/fs/cgroup/cpu/user/$$/tasks
fi
Linux terminal:
mount -t cgroup cgroup /sys/fs/cgroup/cpu -o cpu
mkdir -m 0777 /sys/fs/cgroup/cpu/user
Further more, a reply to Lennart's email states that his approach is actually better then the actual Kernel patch:
I've done some tests and the result is that Lennart's approach seems to work best. It also _feels_ better interactively compared to the vanilla kernel and in-kernel cgrougs on my machine. Also it's really nice to have an interface to actually see what is going on. With the kernel patch you're totally in the dark about what is going on right now.
-Markus Trippelsdorf
The reply also includes some benchmarks you can see @ http://lkml.org/lkml/2010/11/16/392
Found all this here (Ubuntu patch info too):
http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html
Related
Hey all,
The 2.6.38.2 Kernel is out for the Nexus 1. It includes a lot to be excited about like the automatic process grouping. They say users will really be able to notice the new changes.
According to Phoronix testing done on the Mike Galbraith-developed patch in November, the patch can reduce latency by a factor of 10, with noticeable improvements in 1080p video playback. At the time, Torvalds wrote "It is a huge improvement" and makes group scheduling "a killer feature."
Click to expand...
Click to collapse
http://www.desktoplinux.com/news/NS6031587360.html
When do you think someone will get a 2.6.38.x kernel going for the NS? How much of a boot do you think we'll see?
Netarchy is already working on it http://forum.xda-developers.com/showpost.php?p=12542701&postcount=1736
Designed for honeycomb 3.2+ and Iconia a500 only.
Includes:
Sched autogroup
Undervolted & overclocked up to 1646mhz (is set at 1000mhz on boot overclock with setcpu as desired) sweet spot for max stability seems to be ~1504mhz.
GPU overclocked to 133% of stock
JCRU
VR io-scheduler (sio & bfq are included)
Option & cifs & tun & UTF8 are compiled in
Smartassv2 & lagfree gov (interactive as default)
Correctly reports sn & snid for full gameloft compatibility
Mass storage enabled (use script included)
Patched ufsd.ko (acer's ntfs module) for use with 2.6.36.4+ kernel
Most debugging is turned off
Wifi sleep of death is fixed
Many other performance and upstream tegra 2 patches see github for full list.
Suggestions for best performance:
In init.picasso.rc in boot.img's ramdisk make these modifications for best I/O performance on ext4
Code:
mount ext4 /dev/block/mmcblk0p3 /system wait ro noatime nodiratime
mount ext4 /dev/block/mmcblk0p8 /data wait noatime nosuid nodev nodiratime noauto_da_alloc
mount ext4 /dev/block/mmcblk0p4 /cache wait noatime nosuid nodev nodiratime noauto_da_alloc
mount ext4 /dev/block/mmcblk0p6 /system/vendor wait ro noatime nodiratime
The above could also be changed by an init.d script.
Use of mass storage:
From a root # shell with terminal emulator or from adb shell:
Code:
mass_storage on -- to enable
mass_storage off -- to disable
Special Note:
Acer 3.2's kernel source has the "Insert Sim" warning on lock screen
It can be disabled by adding ro.carrier=wifi-only to your /system/build.prop
Kernel is packaged in koush's anykernel so it will replace the kernel & ko's only keeping your ramdisk unmodified for maximum compatibility with a wide variety of roms.
Special Thanks:
Richard Trip for his Iconia kernel source & overclocking code
Caz70 for the snid & sn framework (I made a small change to get it 100%)
GPL source use devel2 branch
Download section:
iconia_gnm_rc1.zip
md5sum e002e5b72478302551479a3a0353cb9b iconia_gnm_rc1.zip
iconia_gnm_rc2.zip
md5sum b7d5c7b7e518b07e5f213bc02ef17edc iconia_gnm_rc2.zip
Changelog
rc2
Updated drivers from a200 source
Fixed kernel crash from usb/ehci
Updated bcm4329 from a200 src now has wifi auto tx-power mode for power savings.
Fix potential null causing kernel crash.
Wifi will now fully power off after a few minutes if wifi-off when screen off is selected.
Fixed wired jack resume.
A pity we can't have some love for A501 tablet owners...
I used to use your Imagio Roms. Great to see you here. I still see some of those wm 6.5 features just making their way to Android.
Hmmmm.... I suppose this kernel will run on a 501 Dres? I know you said 500, but I suppose it's because you couldn't test it?
But it's going to depend on how low you under-volted the frequencies. If it's too low, it will freeze the 501 when on internal 3g.
So if you were to compare frequencies and voltage, which version of RTripp's kernel would you compare it with. As anything higher than his 3.4+, will freeze the 501 eventually.
But, it's damn nice to see a new kernel here at xda.
This looks great. How did you overclock the GPU?
Moscow Desire said:
Hmmmm.... I suppose this kernel will run on a 501 Dres? I know you said 500, but I suppose it's because you couldn't test it?
But it's going to depend on how low you under-volted the frequencies. If it's too low, it will freeze the 501 when on internal 3g.
So if you were to compare frequencies and voltage, which version of RTripp's kernel would you compare it with. As anything higher than his 3.4+, will freeze the 501 eventually.
But, it's damn nice to see a new kernel here at xda.
Click to expand...
Click to collapse
Can you give me the voltages @freqs from that kernel that work on a501. You can get them easily from setcpu voltage tab
drellisdee said:
Can you give me the voltages @freqs from that kernel that work on a501. You can get them easily from setcpu voltage tab
Click to expand...
Click to collapse
Sure, give me a little bit. Have to call parents on skype, then I will send you screen caps from RTripps 3.4+
Then, I will check your current kernel. I love kernels
MD
Screen Caps
Sorry for the delay. Family first, especially when they live on the other side of the world.
2 jpgs, taken from system tuner.
MD
The only diff in voltage is at 1.6. You run about 25mv higher than the 3.4+ kernel.
EDIT: After Antutu, I get 7375. About 40pts above my usual. Note that I am running daily driver.
I guess, I need to flash back to my base install to get a good reading. Also, fps was +1 on what I normally get.
I will need to have about 5 days though, under 3g only, to give my approval for the 501.
These are just first impressions. But so far, no issues with the 501.
I no nothing about kernels but i do overclock my tab and under volt so comparing thor's to this what benefits do we get?
please don't drag me backwards through broken glass for using his name here im just interested in a comparison.
joe9002 said:
I no nothing about kernels but i do overclock my tab and under volt so comparing thor's to this what benefits do we get?
please don't drag me backwards through broken glass for using his name here im just interested in a comparison.
Click to expand...
Click to collapse
I was thinking more like "hot coals".... broken glass is so... superficial.
Here's the deal. Unless you haven't noticed, there are only 2 kernel Dev's. RichardTripp and Thor.
Of course they both have really good kernels. And they are both some of the best Devs. Nobody can argue that (and please, this is not the place for GPL arguements, so people, don't start it)
The issue, is that they developed these kernels, for the a500, because they don't have 501's. And in the quest for the maiximum undervoltage to extend battery life, they forgot about everything else. Like internal 3g for the 501's. Yes, 501's are very sensitive to this.
Also, it seems they forgot about GPU, although that technically, is a seperate area.
So when a Dev puts out a new kernel, it deserves to be tested. Perhaps there is something extra that other devs missed.
So the answer, is yes. It's a big deal.
MD
I will sit back and wait for some feed back then hoping for a comparison im hoping to learn some thing new im getting a bit fed up with my DHD.
joe9002 said:
I no nothing about kernels but i do overclock my tab and under volt so comparing thor's to this what benefits do we get?
please don't drag me backwards through broken glass for using his name here im just interested in a comparison.
Click to expand...
Click to collapse
Not to open a can of worms but I haven't used his kernel nor have I seen his source so I can't really compare it.
Moscow Desire said:
I was thinking more like "hot coals".... broken glass is so... superficial.
Here's the deal. Unless you haven't noticed, there are only 2 kernel Dev's. RichardTripp and Thor.
Of course they both have really good kernels. And they are both some of the best Devs. Nobody can argue that (and please, this is not the place for GPL arguements, so people, don't start it)
The issue, is that they developed these kernels, for the a500, because they don't have 501's. And in the quest for the maiximum undervoltage to extend battery life, they forgot about everything else. Like internal 3g for the 501's. Yes, 501's are very sensitive to this.
Also, it seems they forgot about GPU, although that technically, is a seperate area.
So when a Dev puts out a new kernel, it deserves to be tested. Perhaps there is something extra that other devs missed.
So the answer, is yes. It's a big deal.
MD
Click to expand...
Click to collapse
I got the gpu oc from richard trip btw. The mass storage is new to iconia though and is also featured in my recovery. Does the sn & snid report correctly on an a501 also?
drellisdee said:
Not to open a can of worms but I haven't used his kernel nor have I seen his source so I can't really compare it.
Click to expand...
Click to collapse
It's ok dude. Nobody has seen his source, except Digitex. At least for the ICS.
As with your kernel, I can say this,
With benchmarks on my stock install, it's on par with RT's 3.4+ on wifi and 3g. Base install.
However, under load with apps installed, including 3BP Shell launcher, which is a big resource pig, it is consistantly about 40-50+ points overall. Running antutu benchmark. on 3g.
So something you did, gave it just a tad bit of boost, at least when under a load. Would be nice, if you could put the "death grip" on it, and squeeze just a touch more. Probably in the GPU area.
Nice job Dres....
Hi drellisdee, thanks a lot for your work.
My A501 (but I don't use 3G) don't boot with this kernel and civato's Rom.
In fact, boot stops at the first screen, the black one with the white inscription "ACER". Any idea?
Reno_kun said:
Hi drellisdee, thanks a lot for your work.
My A501 (but I don't use 3G) don't boot with this kernel and civato's Rom.
In fact, boot stops at the first screen, the black one with the white inscription "ACER". Any idea?
Click to expand...
Click to collapse
Did you do a Dalvik wipe before installing?
---------- Post added at 12:35 AM ---------- Previous post was at 12:27 AM ----------
Here's what I know about Civato's rom. The Thor 3.9r3 kernel, is tied in with some other files that enable to give native NTFS support.
It's possible that Dres's kernel, may break that connection.
And that;s what gives you the stuck at acer screen.
Just a guess.
But try wiping dalvik. then install.
Yes, before and after to be sure
Moscow Desire said:
Did you do a Dalvik wipe before installing?
---------- Post added at 12:35 AM ---------- Previous post was at 12:27 AM ----------
Here's what I know about Civato's rom. The Thor 3.9r3 kernel, is tied in with some other files that enable to give native NTFS support.
It's possible that Dres's kernel, may break that connection.
And that;s what gives you the stuck at acer screen.
Just a guess.
But try wiping dalvik. then install.
Click to expand...
Click to collapse
Its doubtful that a module for ntfs could break booting. You will need to check the init.rc's for changes and also init.d scripts. If you could get a shell connection and do a dmesg & logcat that would be very usefull.
With that said this kernel is built from a500 source and I cannot support a 501 as I dont have one. If it works on some 501 setups thats a bonus but wasn't intended to work.
Some guys found a huge optimization for Linux kernel and Dalvik as well on ARM platforms. Actually it is not made by optimizing the code, but by the way GCC compiles, and it increased the performances from 30% to 100%. There is a little video of them running a benchmark on two Android development platforms, the two development platforms are the same. Here it is :
So the ROM used is the same used by the Galaxy Nexus, and Cyanogen Mod now uses it to gain these 30%~100%. What are your feelings about it ? Are you pessimistic, optimistic about the implementation for example for stock Atrix ROMs ? Or community ROMs maybe ? Also tell us if you have some news about it.
So this optimization was made mainly for the Linux kernel on ARM devices, which means it will be way more efficient on ARM computers/servers. This is a great step forward for Linux on embedded platforms. They also worked on Dalvik, so now even Android apps will run faster.
(Sorry for my grammar if I made some mistakes, just tell me I'll correct them.)
Very impressive performance increase. Looking forward to seeing these optimizations make there way into custom roms.
Can you post more info about how this works? Or a link to the original GCC discovery?
Linaro is a hot topic in the Samsung forums. Even the OG SGS (basically half the specs of the Atrix) users are begging support for it...
Sent from my MB860 using XDA Premium App
It will be implemented in the aokp #39 release.
Inviato dal mio Atrix con Tapatalk
AkaGrey said:
It will be implemented in the aokp #39 release.
Inviato dal mio Atrix con Tapatalk
Click to expand...
Click to collapse
how do you know that???
facuxt said:
how do you know that???
Click to expand...
Click to collapse
http://www.droid-life.com/2012/06/1...stem-performance-boosts-are-quite-noticeable/
Sent from my MB860 CM7.2 RC3 36p Radio
It seems it is not easy to get this to work on every CM device. Some people report issues with this patch: http://r.cyanogenmod.com/#/c/17535/
v.k said:
It seems it is not easy to get this to work on every CM device. Some people report issues with this patch: http://r.cyanogenmod.com/#/c/17535/
Click to expand...
Click to collapse
It may not be easy, but I got a feeling that many people from CM teams everywhere are gonna work round the clock to get this to work on their devices.
I'm definitely not a "benchmark guy", and generally shrug off those topics, but even I was blown away after watching this video...
Sent from my MB860 using XDA Premium App
Wow. Awesome!
Imagine that guy talking one on one with a girl though......
Sent from my MB860 using XDA
rancur3p1c said:
Can you post more info about how this works? Or a link to the original GCC discovery?
Click to expand...
Click to collapse
Well all is about the compilation, they didn't change the code but the way GCC compiles it, it is now optimized for the ARM instruction set. So, why wasn't it optimized before the "discover" ? Well I think they didn't take enough time on build optimization when they made GCC working with ARM. First it was made for x86, x64 etc. These are other instruction set, another list of commands the CPU is able to work with. Imagine the instruction sets like different languages. x64, the first one, has a rich vocabulary, and ARM the second one has a more restricted vocabulary but the two languages have the same syntax. The difference will be that you will need to use more words with ARM than with x64 to describe something complex, so now it has to be optimized to use the fewer words possible to be faster. And that's basically what the Linaro Team did.
So the optimization has been used for the Android System (Linux kernel + Dalvik, etc.) but it can also be used for any other ARM program. This is a great step forward also for ARM computers, and maybe ARM servers that will continue to use less energy for bigger tasks because of the optimization.
Slymayer said:
Well all is about the compilation, they didn't change the code but the way GCC compiles it, it is now optimized for the ARM instruction set. So, why wasn't it optimized before the "discover" ? Well I think they didn't take enough time on build optimization when they made GCC working with ARM. First it was made for x86, x64 etc. These are other instruction set, another list of commands the CPU is able to work with. Imagine the instruction sets like different languages. x64, the first one, has a rich vocabulary, and ARM the second one has a more restricted vocabulary but the two languages have the same syntax. The difference will be that you will need to use more words with ARM than with x64 to describe something complex, so now it has to be optimized to use the fewer words possible to be faster. And that's basically what the Linaro Team did.
So the optimization has been used for the Android System (Linux kernel + Dalvik, etc.) but it can also be used for any other ARM program. This is a great step forward also for ARM computers, and maybe ARM servers that will continue to use less energy for bigger tasks because of the optimization.
Click to expand...
Click to collapse
You lost me at compilation...lol
Sent from my MB860 using XDA
So they found a way to optimize compilation for arm architecture yielding massive performance boosts over current standards.. do want =D
These dudes rock.
Sent from my MB860 using XDA
michaelatrix said:
You lost me at compilation...lol
Sent from my MB860 using XDA
Click to expand...
Click to collapse
They found a way to talk to the system by saying less. Like if I would say to you, " hello, how are things in your life" but now I say, "how's things" and you understand both phrases mean the same thing. You get to the conclusion faster because you process less information but reached the same outcome. It takes less processing for the shorter phrase and improves overall response time.
Sent from my MB860 using xda premium
i don't think it'll be easy to use it for our beloved atrix, the linaro code uses a 3.2 kernel, and we're still stuck on the crappy froyo 2.6.32 kernel =/
Update
All the changes I made were merged into CoCore-refresh kernel (3.0.31) and 3.0.101 by TeamCanjica, so they will hit 'mainstream' in some time when they release another build.
This thread is over
/Update
Hi,
I've been working on this kernel for some time with improving undervolting in mind. It's based on CoCore Refresh r10 by CoCafe and of course the credit goes to him where it's due.
Main changes:
- rewritten liveOPP internals.
It improved stability a lot - it now allows to use 300/500/700/900 MHz frequencies with no problem and it allows to undervolt low frequencies even more. Freqs >1GHz are now stable at varm=0x32 (at least on my phone), which also saves a lot of power.
Freqs <=400 MHz now use 0x12 (0.925V) voltage by default - It's the original voltage for 400MHz and you can go even lower when undervolting
- rewritten Mali booster algorithm.
It's far from perfect yet, but it eliminated instability due to the fact, that CoCafe's mali booster and "original" booster (switching between APE 50/100 OPP) were working independently and could cause a crash when the original algorithm switched to APE_50_OPP while mali boost was active. APE_50_OPP voltage is 1V by default (0x18), so when clock is boosted to i.e. 700MHz and it switched to 50 OPP, the result was 350MHz @ 1V, which mihgt be too low.
- allow to set APE and DDR OPP with liveOPP
echo apeopp=25/50/100 > arm_stepXX and echo ddropp=...
before the kernel would set ape/ddr opp to 100 for freqs above 400MHz
- allow changing ape_50_opp voltage
echo 0xXX > /sys/kernel/mali/mali_gpu_vape_50_opp
- make wlan/mmc boost tunables available through sysfs in /sys/kernel/performance/*
- Memory split changed to 2G/2G and switch highmem off - it's not needed with this split
- removed some unnecessary drivers and moved others to modules to reduce kernel size
- changed kernel compression to LZO
- 631MB available memory
- 7800ms kernel boot time
Download & install:
Mediafire
That's partition image - flash it with dd:
Code:
dd if=kernel.mk-r1-release.img of=/dev/block/mmcblk0p15
It's also good to create a symlink from /system/lib/modules to /lib/modules - it'll allow modules to autoload, enable modprobe to work and also you can use KoControl app to manage module loading.
Source:
GitHub
TODO:
- create a package for flashing with recovery and place modules (7MB) in /system/lib/modules instead of a ramdisk
- touchbooster has a bug that causes it to limit max freq to 1000MHz on boost.
- figure out how to enable setting of minimal cpu freq - now touchboost always resets it to 100MHz
- add interactive gov from Zwliew kernel
- create more power optimized, auto tuning 'foreground' governor (long story)
My voltage settings
(default kernel voltages are more conservative - set those from init scripts and test them for stability!):
100 - 0x0f
200 - 0x10
300 - 0x11
400 - 0x12
500 - 0x14
600 - 0x18
700 - 0x1d
800 - 0x24
900 - 0x28
1000 - 0x2f
1050..1250 - 0x32
Mali gpu voltage
Default voltage from CoCafe is way too high - idx0 vape could be just 1V since that's the voltage, when mali is running at 1/2 speed (200MHz by default).
My settings (for safety they are 3 steps higher than the lowest working voltage for given freq).
#0 - 0x17
#5 - 0x1c
#9 - 0x23
I don't overclock the gpu - my low index is set to 0 (200MHz), and hi (boosted) to 5(400MHz), which is the original mali freq. That gives mi 100MHz when working at half speed. I don't use any fancy UI effects, so it's enough - when not plaing a game, mali is only working at 100/200MHz and only boosts when loaded. Params:
boost_low idx=0
boost_low threshold=30
boost_delay 2000
boost_high idx=5
boost_high threshold=220
Default kernel settings are left unchanged - set those manually from init scripts.
I place the thread here because I'm not allowed to post in developer forums (<10 messages limit).
MK
Wow. Thanks for your work, mate!
Most people are using CM or CM/AOSP based ROMs nowadays, but there are only a few people (like me) who still use Jellybean. So, I'll try your kernel very soon and I'll post a review after using it.
You joined XDA on 2010 and yet, this is your first post. That just doesn't feel right.. Anyways, keep up the good work, mate. :good:
Good to see another kernel developer for our phone! I'm on stock rom now, I will try it out
Sami Kabir;5571pro. [B said:
Wow. Thanks for your work, mate! [/B]
Most people are using CM or CM/AOSP based ROMs nowadays, but there are only a few people (like me) who still use Jellybean. So, I'll try your kernel very soon and I'll post a review after( using it.
Click to expand...
Click to collapse
The code is on github and there's no problem with merging it with some cm kernel. When I'll try my with some 4.4 again (so far each one had something broken and didn't suit me), I'll probably do it
You joined XDA on 2010 and yet, this is your first post. That just doesn't feel right.. Anyways, keep up the good work, mate. :good:
Click to expand...
Click to collapse
To keep it short let just say that I'm not a sociable type of guy... but when I have something of value, I try to share...
One more thing (most probably know it, but for those who don't) - 99% of "user experience" depends on the settings of governor, mali and touch booster - if you screw this up, no kernel will work smoothly. I had this problem with my first vanilla jb - it sucked as hell(ondemand), but when I set sampling_down_factor to 3-4 suddenly it was very smooth. Default gov params aren't always the best. Thats one of the reasons I'll try to write a governor that tunes itself and adjusts itself to the app currently in foreground - but that's just an idea and it'll take me some time to refresh all the math needed for it...
Anyway - enjoy the kernel.
Hmm I really wanna test this kernel, but I'm currently on Vanir
I definitely gonna follow your thread, it's good to know Janice is still alive and kicking
Reinkaos said:
Hmm I really wanna test this kernel, but I'm currently on Vanir
I definitely gonna follow your thread, it's good to know Janice is still alive and kicking
Click to expand...
Click to collapse
You can always ask rom's devs to merge my changes - it's just a few commits.
And how is that rom working for you? At the time I was checking up 4.4 roms each one of them sucked in a different way. Carbon was the closest (in fact it was the only one acceptable) to being useful (feature- and ui-wise), but it had some process spinning in the background and It was draining my batt (it was unkillable because it was a part of lock screen I think - the bug was known, but no fix available at that time).
If it's similar to carbon I might give it a try...
mkaluza said:
You can always ask rom's devs to merge my changes - it's just a few commits.
And how is that rom working for you? At the time I was checking up 4.4 roms each one of them sucked in a different way. Carbon was the closest (in fact it was the only one acceptable) to being useful (feature- and ui-wise), but it had some process spinning in the background and It was draining my batt (it was unkillable because it was a part of lock screen I think - the bug was known, but no fix available at that time).
If it's similar to carbon I might give it a try...
Click to expand...
Click to collapse
Well I use to be a Carbon die-hard fan before, but since the dev have got himself another device, so I just had to change rom.
And then I try Vanir. Surprisingly it's pretty stable, and we have official support by the Vanir team too.
Feature-wise its just as good as Carbon, but I kinda miss the pie, since Vanir doesn't have it.
And I think Vanir have a bit more features than Carbon do.
Anyway can you go lower than those cpu voltage on your OP? Or is it really not stable?
Mine's 1000 is at 0x2c, 800 at 0x20, and that's the lowest I can go.
And thanks for the gpu voltage :good: , I actually use that value now :laugh:
aioreu the
Reinkaos said:
Well I use to be a Carbon die-hard fan before, but since the dev have got himself another device, so I just had to change rom.
Click to expand...
Click to collapse
It's a pity... but I understand that's only the S Advance branch of Carbon thats dead - the rom itself is being developed further?
And then I try Vanir. Surprisingly it's pretty stable, and we have official support by the Vanir team too.
Feature-wise its just as good as Carbon, but I kinda miss the pie, since Vanir doesn't have it.
And I think Vanir have a bit more features than Carbon do.
Click to expand...
Click to collapse
I didn't like the pie ;P But if you say it's ok, I'll give it a try when I'm in the mood to reinstall everything on the phone...
Anyway can you go lower than those cpu voltage on your OP? Or is it really not stable?
Mine's 1000 is at 0x2c, 800 at 0x20, and that's the lowest I can go.
Click to expand...
Click to collapse
Actually I didn't recheck those two and focused on lower freqs - these were the limits with older LiveOPP, but now I can go to 0x22 and 0x2c.
In fact, 0x24 and 0x2f are already undervolted values - original are 0x28 and 0x32. But every bit counts, especially on higher freqs.
Thanks for the tip
But what's more interesting - 900MHz works at 0x23 (didn't test that before - just took a voltage halfway between 800 and 1000)... there's something wrong with this ARM_100_OPP, but I don't know what yet... Will test the rest again later and post my results.
And thanks for the gpu voltage :good: , I actually use that value now :laugh:
Click to expand...
Click to collapse
Your welcome
When I have time, I'll try to write how to quickly check undervolting limits for both cpu and gpu.
Mk
mkaluza said:
It's a pity... but I understand that's only the S Advance branch of Carbon thats dead - the rom itself is being developed further?
Click to expand...
Click to collapse
Yes, only for our device. It's not really dead yet.
The dev has been kind enough compiling new one once in a while.
I didn't like the pie ;P But if you say it's ok, I'll give it a try when I'm in the mood to reinstall everything on the phone...
Click to expand...
Click to collapse
Yeah, I could understand that. Too much of a hassle. Got to reinstall everything back again.
But you know, I always do clean flash, even with nightlies. Imagine backing up, factory reset and restoring everything in every 3-4 days.
But now I get really used to it
Actually I didn't recheck those two and focused on lower freqs - these were the limits with older LiveOPP, but now I can go to 0x22 and 0x2c.
In fact, 0x24 and 0x2f are already undervolted values - original are 0x28 and 0x32. But every bit counts, especially on higher freqs.
Thanks for the tip
But what's more interesting - 900MHz works at 0x23 (didn't test that before - just took a voltage halfway between 800 and 1000)... there's something wrong with this ARM_100_OPP, but I don't know what yet... Will test the rest again later and post my results.
Click to expand...
Click to collapse
No problem man, thought that information would be useful to you.
Yeah, it would be really nice to go lower, especially on 1000 and 800.
I'm gonna test the rest, and later I would let you know the lowest working voltage that I can go.
And honestly, I have no idea about kernel stuffs :silly: The least that I can do is to play around with it
Your welcome
When I have time, I'll try to write how to quickly check undervolting limits for both cpu and gpu.
Mk
Click to expand...
Click to collapse
Yes, please do. I would really appreciate that :fingers-crossed:
Reinkaos said:
Yes, only for our device. It's not really dead yet.
The dev has been kind enough compiling new one once in a while.
Click to expand...
Click to collapse
He also left a repo with build scripts and manual, so I'll try to build the rom.
Yeah, I could understand that. Too much of a hassle. Got to reinstall everything back again.
But you know, I always do clean flash, even with nightlies. Imagine backing up, factory reset and restoring everything in every 3-4 days.
But now I get really used to it
Click to expand...
Click to collapse
That's hardcore ;P I have patience to do it 1-2 times a year
Yeah, it would be really nice to go lower, especially on 1000 and 800.
I'm gonna test the rest, and later I would let you know the lowest working voltage that I can go.
Click to expand...
Click to collapse
mine crashed at 1000MHz/0x2c - I'm on 0x2d now and it seems ok
And honestly, I have no idea about kernel stuffs :silly: The least that I can do is to play around with it
Click to expand...
Click to collapse
You could always learn It's fun, all the info is there to read for free... all it takes is will and time
Yes, please do. I would really appreciate that :fingers-crossed:
Click to expand...
Click to collapse
I still cant post links, so you need to go to my github (mkaluza), open the i9070_kernel_CoCore-E repo and go to wiki on the right - there is a page "Undervolting janice". Hope this helps.
Mk
mkaluza said:
He also left a repo with build scripts and manual, so I'll try to build the rom.
Click to expand...
Click to collapse
Well that's a good news :good:
That's hardcore ;P I have patience to do it 1-2 times a year
Click to expand...
Click to collapse
LOL yeah
mine crashed at 1000MHz/0x2c - I'm on 0x2d now and it seems ok
Click to expand...
Click to collapse
I'm not sure if mine is really stable, gonna test it with your guide on github
You could always learn It's fun, all the info is there to read for free... all it takes is will and time
Click to expand...
Click to collapse
Yeah, I am learning right now
I still cant post links, so you need to go to my github (mkaluza), open the i9070_kernel_CoCore-E repo and go to wiki on the right - there is a page "Undervolting janice". Hope this helps.
Mk
Click to expand...
Click to collapse
So there are scripts that will provide me with some infos when doing UV-ing
And I'm not familiar with registers though, I only do it via liveopp, but still I'll try this
Thanks for the guide
Anyway I got a question about gpu, lets say my mali low_boost is 400 and high_boost is 480,
does it use the two freq only or it use the other freq in between 400 and 480 too?
P.S. hey you could just spam in OT threads to get 10 posts
Reinkaos said:
I'm not sure if mine is really stable, gonna test it with your guide on github
Click to expand...
Click to collapse
If you don't get random reboots/crashes than it is - when following my guide, the resulting voltage should be stable, but it isn't always so... I'ts just a starting point that can save you some initial crashes or the other way around - if it doesn't pass freq_jump test, then it isn't stable for sure
Anyway I got a question about gpu, lets say my mali low_boost is 400 and high_boost is 480,
does it use the two freq only or it use the other freq in between 400 and 480 too?
Click to expand...
Click to collapse
Only those two - three actually - also 200MHz (that is low_boost/2), but with ape_50_opp voltage, not the one from dvfs_config. There's not much point in doing any smarter gov because gpu intensive apps usually load it at 100% no matter how much power it has - they just have more fps then.
.P.S. hey you could just spam in OT threads to get 10 posts
Click to expand...
Click to collapse
Yeah, maybe, but if those are the rules, then I try to respect them - because I respect the community. (not because I'm some kind of by-the-book guy ;P I ride motorcycle and have already broken so many rules, that they would put me behind bars for life if anybody kept the count ;P).
mkaluza said:
I ride motorcycle and have already broken so many rules, that they would put me behind bars for life if anybody kept the count ;P).
Click to expand...
Click to collapse
You like adrenaline, heh
PS: Sorry for OT
mkaluza said:
If you don't get random reboots/crashes than it is - when following my guide, the resulting voltage should be stable, but it isn't always so... I'ts just a starting point that can save you some initial crashes or the other way around - if it doesn't pass freq_jump test, then it isn't stable for sure
Click to expand...
Click to collapse
Hey, just letting you know, about opptop script, we don't have prcmu-qos folder in /debug. I thought maybe it have a different name, but I couldn't find ape_requirements and ddr_requirements. The others are working fine
Only those two - three actually - also 200MHz (that is low_boost/2), but with ape_50_opp voltage, not the one from dvfs_config. There's not much point in doing any smarter gov because gpu intensive apps usually load it at 100% no matter how much power it has - they just have more fps then.
Click to expand...
Click to collapse
Thanks for the infos :good:
Yeah, maybe, but if those are the rules, then I try to respect them - because I respect the community. (not because I'm some kind of by-the-book guy ;P I ride motorcycle and have already broken so many rules, that they would put me behind bars for life if anybody kept the count ;P).
Click to expand...
Click to collapse
LOL, I'm curious though, what bike do yo own? Must be a real badass one
Force said:
You like adrenaline, heh
PS: Sorry for OT
Click to expand...
Click to collapse
I'ts more about freedom and versatility, but yeah sometimes I like to push it too
Reinkaos said:
Hey, just letting you know, about opptop script, we don't have prcmu-qos folder in /debug. I thought maybe it have a different name, but I couldn't find ape_requirements and ddr_requirements. The others are working fine
Click to expand...
Click to collapse
I forgot... this feature was written by me, so it's available only on my kernel for the moment. But it's not really that important - it was more for debugging purposes for me, now I left it as informative.
I'm trying to build Carbon rom for out phone since last night... when/if I'm done, I'll patch the kernel with my stuff and push it somewhere. What is your kernel version? I think that both carbon and vanir use the same, or at least similar one.
LOL, I'm curious though, what bike do yo own? Must be a real badass one
Click to expand...
Click to collapse
Not really I't an old BMW F650 - only 48 ponies (of which some might have already died of old age ;P). But in reality you can do most of the fun stuff with as little as 125cc Anything bigger is usefull for longer trips/highways/trips with passenger/etc... I mostly ride small country roads and light offroad, so I rarely go over 100km/h, so no badass machine is needed something like 350cc would be best I think. Actually - it's not the bike you ride, but how you ride it... and on narrow roads with many turns a bigger bike is event sometimes harder to ride...
mkaluza said:
I forgot... this feature was written by me, so it's available only on my kernel for the moment. But it's not really that important - it was more for debugging purposes for me, now I left it as informative.
I'm trying to build Carbon rom for out phone since last night... when/if I'm done, I'll patch the kernel with my stuff and push it somewhere. What is your kernel version? I think that both carbon and vanir use the same, or at least similar one.
Click to expand...
Click to collapse
Well ok then. Vanir got a 3.0.101 kernel. It's the same I think? I'll flash and test it when you're done, definitely.
Not really I't an old BMW F650 - only 48 ponies (of which some might have already died of old age ;P). But in reality you can do most of the fun stuff with as little as 125cc Anything bigger is usefull for longer trips/highways/trips with passenger/etc... I mostly ride small country roads and light offroad, so I rarely go over 100km/h, so no badass machine is needed something like 350cc would be best I think. Actually - it's not the bike you ride, but how you ride it... and on narrow roads with many turns a bigger bike is event sometimes harder to ride...
Click to expand...
Click to collapse
lol the biggest one I ever been on is about 130 cc. It's small, enough that you could squeeze through traffics
I don't know much about bike, but AFAIK those superbike need different kind of handling too.
Let's speak just about this kernel as for this is meant this thread
Please anyone tell me how to find the kernel link . I`m a noob at this part :silly: Thanks
pictorul20 said:
Please anyone tell me how to find the kernel link . I`m a noob at this part :silly: Thanks
Click to expand...
Click to collapse
Go here and see download link at top of page: https://github.com/mkaluza/i9070_kernel_CoCore-E
Download link : http://goo.gl/FvqPlg
Then check OP to see how to install it.
Force said:
Go here and see download link at top of page: https://github.com/mkaluza/i9070_kernel_CoCore-E
Download link : http://goo.gl/FvqPlg
Then check OP to see how to install it.
Click to expand...
Click to collapse
Many Thanks.
I see a lot of people are quick to flash AK, Franco, Tyr, etc before they even give the kernel that comes with the ROM a try.
From my personal experience, the kernel that comes with a ROM is always faster & snappier than aftermarket kernels (no overclocking).
Also, correct me if I'm wrong, but the kernel that comes with the ROM is optimized to perform best with the ROM. Optimization is the main reason why Android is one step behind of iPhones. I don't know about you guys, but I want my phone to be fully optimized which is why I stick with the stock kernel most of the time.
I guess I'm also one of these people who are quick to flash a aftermarket kernel.
But I think the aftermarket ones are the more optimized ones.
Anyway I never had problems with the stock kernels.
I love the extra work devs like Franco and AK do. Sometimes I get some reboots with Franco but overall its a good experience. I just have some Franco loyalty from when I used his kernel on nexus 4 lol best kernel ive ever used. Not sure if I'd say the same about his one plus kernel but if there's any issues I'd blame cm not him
Klobal said:
I guess I'm also one of these people who are quick to flash a aftermarket kernel.
But I think the aftermarket ones are the more optimized ones.
Anyway I never had problems with the stock kernels.
Click to expand...
Click to collapse
I used to be the same way on my older android devices.
It seems like now flashing a kernel is no longer need to improve performance (sorta)
The hardware on the oneplus one is beast & android has come a long way in terms of software.
Because I love the sound control in AK Kernel
jousa11 said:
Because I love the sound control in AK Kernel
Click to expand...
Click to collapse
Better than Viper or DSP?
OmegaBlaze said:
Better than Viper or DSP?
Click to expand...
Click to collapse
I use viper as the audio processor AK's kernel just gives good audio gain without any distortion
OmegaBlaze said:
I used to be the same way on my older android devices.
It seems like now flashing a kernel is no longer need to improve performance (sorta)
The hardware on the oneplus one is beast & android has come a long way in terms of software.
Click to expand...
Click to collapse
I believe the same. I get most battery savings from deleting bloat off the phone.
NJGSII said:
I believe the same. I get most battery savings from deleting bloat off the phone.
Click to expand...
Click to collapse
I do the exact same thing. I try and delete all of the unnecessary google play stuff as well as apps I don't use often. And use greenify as well.
jousa11 said:
I use viper as the audio processor AK's kernel just gives good audio gain without any distortion
Click to expand...
Click to collapse
I definitely have to try that out. I usually always skip pass it lol..
I use franco kernel because I get better battery with his kernel (compared to stock), and it's always up-to-date with most of the patches, while with stock you'll have to wait until the next OTA to get some patches.
NJGSII said:
I believe the same. I get most battery savings from deleting bloat off the phone.
Click to expand...
Click to collapse
Can you please name bloat stuff which still comes with Cyanogenmod what should be deleted? Would be helpful for me to get my phone as clean as possible/neccessary.
m4soN said:
Can you please name bloat stuff which still comes with Cyanogenmod what should be deleted? Would be helpful for me to get my phone as clean as possible/neccessary.
Click to expand...
Click to collapse
Meant that with other phones I have
So, there is no stuff which still comes with systems like cyanogenmod which i can delete without getting any trouble? If yes, how do i know which stuff this can be?
Purchased Franco Kernel Updater and if I didn't use a custom kernel (or Franco Kernel) then I spent money on something I'm no longer using.
Also because I'm not a fan of mpdecision.
zephiK said:
Purchased Franco Kernel Updater and if I didn't use a custom kernel (or Franco Kernel) then I spent money on something I'm no longer using.
Also because I'm not a fan of mpdecision.
Click to expand...
Click to collapse
Same here switching between AK and Franco.
Both are a good choice.
But as mentioned before, the hardware of our phone is :good: so no need to flash a aftermarket kernel to gain more performance.
zephiK said:
Purchased Franco Kernel Updater and if I didn't use a custom kernel (or Franco Kernel) then I spent money on something I'm no longer using.
Also because I'm not a fan of mpdecision.
Click to expand...
Click to collapse
Why not? Intelliplug?
OmegaBlaze said:
Why not? Intelliplug?
Click to expand...
Click to collapse
Anything other than mpdecision, I personally prefer Franco's hotplug algorithm which is his own implementation of powering on/off cores.
Mpdecision is Qualcomm's implementation of powering on/off cores.
I personally am not a fan of Intelliplug,
3 - Don't even bring intelliplug on this. With all due respect to faux, that driver is a butchered solution to control the cores. The code is a mess and, in my opinion, just doesn't make any sense. I've worked on my Hotplug driver for years and it works as simple as need be, with appropriate userspace tunables for users to tinker with.
http://forum.xda-developers.com/showpost.php?p=55667033&postcount=3981
Click to expand...
Click to collapse
http://www.reddit.com/r/nexus4/related/158t1i/custom_kernels_a_guide_on_what_you_need_to_know/ has a great reading on mpdecision and why it is not good in their opinion.
--mpdecision--
All Qualcomm based phones have Qualcomm prorprietary userspace binary called "mpdecision" aka m(ake)p(oor)decision. Instead of letting the kernel itself to decide what frequencies and how many cores to run, this "mpdecsion" binary polls the kernel run queue statistics and decides for the whole system the "optimal" frequency and the "optimal" number of cores to use. The concept is fine, except the decision making is done in userspace and it's 100% closed source so there's no way to tweak it and there's a latency (because all userspace binaries needs to "poll" the kernel for the latest information which is slightly delayed). - faux123
ELI5: mpdecision is a proprietary Qualcomm daemon that makes calls to the SoC (the entire chip your phone uses) to manage the cores. The OS (PowerHAL) makes a request to mpdecision and then mpdecision makes a request to the first two cores to ramp them up. - _motley
Click to expand...
Click to collapse
I like to mess with my phone. Simply because I need a kernel fully optimised kernel for the device. Not to say that the developers aren't doing a good job, but in my case, a user sometimes knows better than the creator themselves.
Unless the custom kernels do not satisfy me, I'll revert back to stock.
m4soN said:
So, there is no stuff which still comes with systems like cyanogenmod which i can delete without getting any trouble? If yes, how do i know which stuff this can be?
Click to expand...
Click to collapse
This phone is fairly clean out of the box. About the only stuff worth freezing or deleting would be some of the google play apps if you don't use them. For example Google play books, news stand, or games.