Related
Curious if any of the nuts and bolts kernel devs have comments on this new kernel patch?
http://www.pcworld.com/businesscent...x_kernel_patch_delivers_huge_speed_boost.html
What a difference 233 lines of code can make. That's the size of a small new patch to the Linux kernel's scheduler that has been found to reduce the average latency of the desktop by about 60 times. It's a small patch with a really, really big gain for desktop users of the open source operating system, in other words.
Click to expand...
Click to collapse
Actual patch:
http://lkml.org/lkml/2010/10/19/123
What a blessing this would be...
Someone submitted patch to Cyan...
Doesn't look good though..
http://review.cyanogenmod.com/#change,417
I actually added the changes to ezterry's kernel last night and left it compiling this morning on my way out the door. My intution says this change wont help much, I already saw a ton of cgroup related code in the kernel... Never know until you try though.
Edit: After reading all the comments I probably won't even try booting the kernel at this point, lol!
The idea behind the patch is that it doesn't increase speed, just usability, which is something Android certainly needs. This was something tested on a 4 core CPU on Linux, so I don't know how much of a benefit it'll be for Android platforms.
Really, using BFS or BFQ scheduler would increase performance more on our phones. Sadly, neither is really stable, and cause memory leaks (on our phones at least)
Why isn't Jit stable yet? It's always disabled, and considered bad to enable.
Jit is actually stable for android. just not used on the G1 and magic because it uses to much memory compared to the bennifits.
on devices with larger RAM it is actually working quite well
This can now be considered stable, after significant testing and use by the community. As always, the hero you save could be your own, so be safe.
This would not have been possible without the efforts of everyone in the community that played a part in moving the ball forward. In particular s0be and riemer for their initial efforts to get a working 2.6.35 build as a baseline, and the continuing efforts of riemer, erasmux, arco, et al; also thanks to toast, darch, decadence, pershoot, and cyanogen, as well as the Linux, CM, AOSP, and CAF teams that have provided the broad shoulders for tinkerers like myself to stand on. My sincere gratitude to all of these and the legion of others who I have not listed, who have contributed to making the open source community strong and productive.
This kernel is based on a combination of updated board files for HeroC, and efforts by arco, riemer, erasmux on new sources originally from the HTC marvel code release. After several weeks on the new base, everything appears to be working well. Initial sources have been posted to github.
New version (2.6.35.14) is at:
https://github.com/TeamHeroC/heroc-kernel-2.6.35
The sources for this Kernel and the AOSP flavored 2.3.5 ROM sources are posted to the TeamHeroC github. This organization github was created instead of using a personal github so that others could join in team development efforts if they are interested, and the organization could be more easily maintained after people move on to other devices. I am probably looking at somewhere between 2-5 months myself.
Flash from recovery, and remember nandroid is your friend.
UPDATE - KERN-2.6.35.14-10SEP-V1.0.zip
10SEP version has been updated with changes from various sources. Github has also been updated to be in sync with this update.
UPDATE - KERN-2.6.35.14-22OCT-V1.1.zip
22OCT version has been updated with changes from various sources. Github has also been updated to be in sync with this update.
Old version - No Longer in Development
This is very much a work in progress, so be safe.
This would not have been possible without the efforts of everyone in the community that played a part in moving the ball forward. In particular s0be and riemer for their efforts to get a working 2.6.35 build as a baseline; also thanks to toast, darch, decadence, pershoot, and cyanogen, as well as the Linux, CM, AOSP, and CAF teams that have provided the broad shoulders for tinkerers like myself to stand on. My sincere gratitude to all of these and the legion of others who I have not listed, who have contributed to making the open source community strong and productive.
This kernel is based on a combination of the s0be/riemer board files and other mods applied to the CyanogenMod cm-kernel android-msm-2.6.35-unified branch. It does not have smartass (not working yet), but the camera seems to work consistently for me on both interactive and ondemand (Note: setting min cpufreq to 352 is recommended to minimize camera problems). This is still very much an early effort, but thought I would post for anyone interested. Initial sources have been posted to github.
https://github.com/TeamHeroC/cm-kernel-heroc
New version (2.6.35.14) is at:
https://github.com/TeamHeroC/heroc-kernel-2.6.35
The approach to building this kernel was to go back to a build based on the last CM 2.6.35 source from the repo and add files from the s0be/riemer source tree to get a working kernel. My goal is to get this as close to standard source as possible, so the changes will just be the device specific board files, drivers, etc. The reason for this approach is to (hopefully) get a well defined set of files and updates that can be applied to other kernel releases (.37, .38, ...) with minimal conflicts and dependencies.
Lots of things that I will be working on as time permits. In no particular order this includes things like:
complete headset updates
update qdsp5_comp to align with latest sources
update smd files to align with latest sources
rework board files to current standards
check and complete i2c updates
complete USB updates
compare and update MSM frame buffer files
cpufreq updates and smartass governor
check and update device specific drivers
The sources for this Kernel and the AOSP flavored 2.3.4 ROM sources are posted to the TeamHeroC github. This organization github was created instead of using a personal github so that others could join in team development efforts if they are interested, and the organization could be more easily maintained after people move on to other devices. I am probably looking at somewhere between 2-5 months myself.
Flash from recovery, and remember nandroid is your friend.
Added No Headset version as suggested by s0be. This version has no headset drivers built in. In theory, this should improve the stability of your USB functions. This has had very little in the way of testing. YMMV.
Thank You,
Flashing now!
painter_ said:
Thank You,
Flashing now!
Click to expand...
Click to collapse
Thank you this great news!!!!!
Sent from my HERO200 using XDA Premium App
Awesome news.
Thanks JB for picking this up.
jaybob413 said:
Flash from recovery, and remember nandroid is your friend.
Click to expand...
Click to collapse
Thanks again Jaybob,
One question, Ive been running the kernel that you posted on s0be's thread a few days back, is this one updated or is it basically the same? So far no Camera bug for me (which is why I flashed to begin with).
chalan30 said:
Thanks again Jaybob,
One question, Ive been running the kernel that you posted on s0be's thread a few days back, is this one updated or is it basically the same? So far no Camera bug for me (which is why I flashed to begin with).
Click to expand...
Click to collapse
A few changes since then, but nothing major. I can't really say whether it is better or worse than the previous. Seems about the same to me. I will add the previous version to the OP later as well.
jaybob413 said:
A few changes since then, but nothing major. I can't really say whether it is better or worse than the previous. Seems about the same to me. I will add the previous version to the OP later as well.
Click to expand...
Click to collapse
Radical.
Thanks for your efforts. The previous version has been working well for me on your May 30th rom with FR 118_15 with some autokiller tweaks. Battery life seems a little worse but still very decent. All very smooth with ADW eX and LPPro . Had a couple of issues with the phone locking up (black screen) for about 20 30 seconds, then coming back on its own. Not sure if it was because my min was too low on setcpu (on demand). Not that it matters but my linpack scores have been consistently lower. but real world performance is great.
Lets see how this does.
so totally didnt see this thread until just now.. thanks a ton jaybob.. this kernel has some loyal followers, and i know i can say for most of them that i am glad to see someone who is capable pick this up.. i was trying my hand at it, but i dont have the time right now, and my knowledge base just isnt as broad as it needs to be for this.. so thanks man, you are the best..
3 Hours now and it seams stable. It took a little while after the first boot before my phone became stable. The ROM I am running the 5/25 version of Evervolv.
painter_ said:
3 Hours now and it seams stable. It took a little while after the first boot before my phone became stable. The ROM I am running the 5/25 version of Evervolv.
Click to expand...
Click to collapse
Yeah these .35 kernels usually take a few minutes to warm up. but they tend to get tremendously better with time..
sent from my... wait.. what..
This thing is running too smooth on the latest nightly. Someone pinch me!!
pstevep said:
Yeah these .35 kernels usually take a few minutes to warm up. but they tend to get tremendously better with time..
sent from my... wait.. what..
Click to expand...
Click to collapse
Its kinda weird how they do that... but they do go nice after a little while!
and jaybob this build is running a lot smoother than the last one.. on a whole, its smooth a silk, camera is working great.. kudos so far man..
jaybob413 said:
(Note: setting min cpufreq to 352 is recommended to minimize camera problems)
Click to expand...
Click to collapse
Isn't camera supposed to engage perflock?
jasonmaloney said:
Isn't camera supposed to engage perflock?
Click to expand...
Click to collapse
No perflock in this kernel (or s0be's or deca's). My recommendation is just based on an observation that when the min cpu freq was set to a very low value (19), I would see a lot of camera freezes. It may work fine at lower settings, I normally have mine set to 352 and don't have camera problems with ondemand or interactive, so this is just what has worked for me. It may also be fine at 264 or 176, but I haven't tried them.
Running this kernel with the latest CM7 nightly and I've never seen my Heroc run so smooth nor get this crazy good battery life.
Thanks JB.
Haven't checked to see if I get my regular reboot after 10 minutes of Google navigation.
I was using sobe's .35 kernel and the camera worked at first but lately wouldn't work at all and I saw that the camera was supposed to be working well with this. Flashed it a little while ago and haven't been able to take a single picture. My cpu is ondemand with a min/max 518/768.
braczkowski said:
I was using sobe's .35 kernel and the camera worked at first but lately wouldn't work at all and I saw that the camera was supposed to be working well with this. Flashed it a little while ago and haven't been able to take a single picture. My cpu is ondemand with a min/max 518/768.
Click to expand...
Click to collapse
i honestly think that right now some of the camera stuff is phone specific.. because i know some people have no issues, asome people have intermittent issues (me), and some people lose it all together.. but thats how it was with s0be's version as well, i think until most of the camera bugs are squashed we will continue to see random issues for random people..
BTW since you already cant use the camera, try switching to interactive for the governor, and try it then.. jaybob said that his works fine with interactive, so maybe your phone will respond better with it.. just a thought, no promises..
352 min cpu fixed my camera issue.
I was browsing the Optimas 2x forum today and ran into an awesome kernel with GPU overclock. which sounds pretty cool to me. also the dev mentioned something about overclocking "system bus" which improvers memory/2D/3D/etc. i think someone in this forum should take a look into this KERNEL and try letting us taste some of this goodness.
Here are the links:
http://forum.xda-developers.com/showthread.php?t=1119771
http://forum.xda-developers.com/showpost.php?p=14654927&postcount=36
while im no genius when it comes to this stuff, somehow i would suspect that people here are already looking into this.
i could be wrong tho lol
pyckvi said:
I was browsing the Optimas 2x forum today and ran into an awesome kernel with GPU overclock. which sounds pretty cool to me. also the dev mentioned something about overclocking "system bus" which improvers memory/2D/3D/etc. i think someone in this forum should take a look into this KERNEL and try letting us taste some of this goodness.
Here are the links:
http://forum.xda-developers.com/showthread.php?t=1119771
http://forum.xda-developers.com/showpost.php?p=14654927&postcount=36
Click to expand...
Click to collapse
The person to ask this to is Morfic. He's all about tweaking bus speeds to improve not only cpu but gpu performance as well. But much of what you've already requested has been incorporated
jlevy73 said:
The person to ask this to is Morfic. He's all about tweaking bus speeds to improve not only cpu but gpu performance as well. But much of what you've already requested has been incorporated
Click to expand...
Click to collapse
But where is he...??
G2X
CPU overclock is something that makes sense for us right now but what would a GPU overclock get us? To me thats just something that will lower the life of our phone with no real reward until games come out that our phone can't run. Right now our phone can run pretty much all games at full speed.
gpu overclocking would be sweet... now my question would be has anyone tried to load Optimas 2x kernel/software on the g2x since they are pretty much the same hardware(in theory you would think it would work)... i might even try to load this kernel onto my phone when i get home from work so if i mess anything up ill have my gear to fix it
crisis187 said:
gpu overclocking would be sweet... now my question would be has anyone tried to load Optimas 2x kernel/software on the g2x since they are pretty much the same hardware(in theory you would think it would work)... i might even try to load this kernel onto my phone when i get home from work so if i mess anything up ill have my gear to fix it
Click to expand...
Click to collapse
Please don't try to load O2x software on your G2x.
pyckvi said:
I was browsing the Optimas 2x forum today and ran into an awesome kernel with GPU overclock. which sounds pretty cool to me. also the dev mentioned something about overclocking "system bus" which improvers memory/2D/3D/etc. i think someone in this forum should take a look into this KERNEL and try letting us taste some of this goodness.
Here are the links:
http://forum.xda-developers.com/showthread.php?t=1119771
http://forum.xda-developers.com/showpost.php?p=14654927&postcount=36
Click to expand...
Click to collapse
I remember reading a while ago that GPU/System bus overclocking was attempted by some kernel dev, then later on, the dev realized through extensive testing that GPU and system bus clocks were locked, the changes to the kernel source had no effect (hardwired). Now this was a few months ago when I was reading up on Tegra kernel development before I got my G2x. Now all these could have been obsolete, and maybe now someone has found a way to do the above via kernel source updates.
Another issue that most people don't mention here and many people have been guilty of, is the GPL issue. The guy who supposedly did this overclocking has not published his kernel source code anywhere (GPL/XDA rules issues), so no one can examine what he did and prove that it worked....
GideonX said:
Please don't try to load O2x software on your G2x.
Click to expand...
Click to collapse
have you tried it yet though is my question
im not worried if i flash a kernel and it doesnt work i can reflash my old kernel if it doesnt work and gets stuck into a bootloop
crisis187 said:
have you tried it yet though is my question
Click to expand...
Click to collapse
Someone in another thread tried this and it messed up their baseband. A restore doesn't fix it apparently.
Big rush dog, the tiamat kernel guru and Guy getting engadet headlines for oc the xoom to 1.7 ghz has gpu oc in his kernels. I will be honest though, I can't tell the difference except maybe video streaming works a little smoother. I personally don't think it is worth the devs time...
Sent from my LG-P999 using XDA App
Howdy! I'm the developer of that kernel
To be honest the GPU overclocks aren't all that beneficial. There is a little bit of a speed bump (I managed to get the highest score on nenamark2 for example). But the difference is was 27fps vs 32fps. If someone is interested in incorporating that into the g2x I'll be happy to show them the changes I've made. I haven't released the source because I'm lazy but there isn't too much to it.
Actually, if you look at the voltKernel sources for the O2X you'll see the same changes there.
chuckhriczko said:
CPU overclock is something that makes sense for us right now but what would a GPU overclock get us? To me thats just something that will lower the life of our phone with no real reward until games come out that our phone can't run. Right now our phone can run pretty much all games at full speed.
Click to expand...
Click to collapse
Yes, superficial benchmarks like quadrant can be pushed to 5400 only with max cpu oc.
However, did you notice how 1.2 thru 1.5 gets you the same fps with no added benefit than more heat created?
Pushing other things other than cpu should let us remove bottlenecks and not tighten them up.
If you want your G2x to life 20yrs, 1.5ghz is not the way to go.
I have no kernel ready for release, to notice changes, I stuck to 1.5ghz, but the final result will be more likely 1.2 or 1.3ghz.
Maybe with a "don't hold my hand, give me freedom or give me death" DBU version at 1.5Ghz later.
I'm not shy to increase vcore on a SoC. But unlike the Nexus S, this thing gets HOT, fast.
Avetny pointed out that thread, I'll see if fallout hit something I have missed so far.
The clocks get compared to chip defaults in many places, choosing the smaller of the two, so it's just tedious replacing them with sane defaults, unless I stick to my current approach of offsets instead of absolutes.
We'll see.
That's also the reason I don't update my kernel often. Right now commits in cm git are only preparatory, config changes that made things smoother I already used.
I'll release something if they finish their version of BLN.
Or if I'm happy with gpu/bus/ram oc/tweaks.
not going to make people flash a kernel for no reason. As jlevy can attest, kernel not following cm git, not even based on it can work very well.
Not having latest cm commit on kernels that take another approach is not always useful.
Especially if we track regressions that cm devs back out later, that's all this gains.
So yes, there will be a gpu oc, when it's ready.
Great!
@ fallout0 thank you i hope that you can help out one of our devs on this.
morfic said:
Yes, superficial benchmarks like quadrant can be pushed to 5400 only with max cpu oc.
However, did you notice how 1.2 thru 1.5 gets you the same fps with no added benefit than more heat created?
Pushing other things other than cpu should let us remove bottlenecks and not tighten them up.
If you want your G2x to life 20yrs, 1.5ghz is not the way to go.
I have no kernel ready for release, to notice changes, I stuck to 1.5ghz, but the final result will be more likely 1.2 or 1.3ghz.
Maybe with a "don't hold my hand, give me freedom or give me death" DBU version at 1.5Ghz later.
I'm not shy to increase vcore on a SoC. But unlike the Nexus S, this thing gets HOT, fast.
Avetny pointed out that thread, I'll see if fallout hit something I have missed so far.
The clocks get compared to chip defaults in many places, choosing the smaller of the two, so it's just tedious replacing them with sane defaults, unless I stick to my current approach of offsets instead of absolutes.
We'll see.
That's also the reason I don't update my kernel often. Right now commits in cm git are only preparatory, config changes that made things smoother I already used.
I'll release something if they finish their version of BLN.
Or if I'm happy with gpu/bus/ram oc/tweaks.
not going to make people flash a kernel for no reason. As jlevy can attest, kernel not following cm git, not even based on it can work very well.
Not having latest cm commit on kernels that take another approach is not always useful.
Especially if we track regressions that cm devs back out later, that's all this gains.
So yes, there will be a gpu oc, when it's ready.
Click to expand...
Click to collapse
thanks morfic i hope everything goes smooth with your kernel, i would love to test it out once u feel it is ready. and thanks for not rushing it.
faux123 said:
I remember reading a while ago that GPU/System bus overclocking was attempted by some kernel dev, then later on, the dev realized through extensive testing that GPU and system bus clocks were locked, the changes to the kernel source had no effect (hardwired). Now this was a few months ago when I was reading up on Tegra kernel development before I got my G2x. Now all these could have been obsolete, and maybe now someone has found a way to do the above via kernel source updates.
Another issue that most people don't mention here and many people have been guilty of, is the GPL issue. The guy who supposedly did this overclocking has not published his kernel source code anywhere (GPL/XDA rules issues), so no one can examine what he did and prove that it worked....
Click to expand...
Click to collapse
You should talk to Fallout0 he seems like he got past the system bus/GPU locked issue. both of you can maybe learn something new from each other. & it would be awesome if the both of you can work on a kernel together.
Wouldn't a higher clocked G2x cause more heat? Heat being the reason this things reboots so often? Maybe a slower G2x is the way to go.
Would overclocking the gpu help run nds4droid any better? What else would ocing the gpu do? Everything seems to be very fast as it is lol
Sent from my LG-P999 using XDA Premium App
dkb218 said:
Wouldn't a higher clocked G2x cause more heat? Heat being the reason this things reboots so often? Maybe a slower G2x is the way to go.
Click to expand...
Click to collapse
Pushing cpu more I don't see useful other than keep up with your buddy's Nexus S' quadrant scores and make sure your hands stay warm in a cold Chicago winter.
I build kernels usually when things stutter or otherwise annoy me. The pushing the OC usually comes by request of those who just want more more more.
I do like to remove bottle necks.
The hardwired clocks. Well the.cpu ones are hardwired too.
The gpu/bus oc works, until boost and throttling kick in, where again values are compared to hardwired values. using offsets after the comparison would be the way around without killing boosting and throttling.
Guess main thing that stopped me is the heat at 1.5ghz, and the frowns over 1.2ghz and 1.3ghz kernels, without further "what else is in there"
Still hoping fallout can share what he/she has, it'll help making this a reality, sooner.
It's tedious. Most of all.
So it would seem that Linaro have done some toolchain optimisation and come up with a version of 4.0.4 AOSP that runs significantly faster than stock AOSP. I searched a little and found all the threads that say that optimised toolchains don't actually do anything, but this seems to be definitive proof that they do.
Here's the link
First I saw a linaro kernel and now im seeing linaro aosp roms. What is the benefits of Linaro(either rom or kernel or both) over stock, or basic aosp or even the big roms like aokp and cm?
Linaro is a toolchain used in the compilation of roms. Its supposed to be extra efficient. Some kernels are compiled with linaro too. Kernel devs seem divided on whether it adds any benefit in a kernel-only build or not.
I tend to not waste energy thinking about it.
-----------------------
Sent via tapatalk.
I do NOT reply to support queries over PM. Please keep support queries to the Q&A section, so that others may benefit
rootSU said:
Linaro is a toolchain used in the compilation of roms. Its supposed to be extra efficient. Some kernels are compiled with linaro too. Kernel devs seem divided on whether it adds any benefit in a kernel-only build or not.
I tend to not waste energy thinking about it.
Click to expand...
Click to collapse
you dont sound too convinced
is it supposed to be better for battery life? better with background services? faster?
i saw one benchmark of linaro with dalvik patches and they're getting the same score i did on cataclysm with bionic/dalvik optimization patches
Enddo said:
you dont sound too convinced
Click to expand...
Click to collapse
Well devs are divided on whether building only a kernel with linaro has benefits or not. I know less than kernel devs so I haven't got an opinion. All I can say is choosing a kernel build with linaro is not on my priorities list.
http://en.m.wikipedia.org/wiki/Linaro
-----------------------
Sent via tapatalk.
I do NOT reply to support queries over PM. Please keep support queries to the Q&A section, so that others may benefit
Enddo said:
you dont sound too convinced
is it supposed to be better for battery life? better with background services? faster?
i saw one benchmark of linaro with dalvik patches and they're getting the same score i did on cataclysm with bionic/dalvik optimization patches
Click to expand...
Click to collapse
it has nothing to do with battery life and background services. all it is is a toolchain used to build roms and kernels. just because the developers of the linaro toolchain published that their toolchain improved performance two years ago, some people now believe it improves performance. compared to what they used as a comparison, it did. but they used an old toolchain to compare it to. but the google toolchain does just as good as the linaro toolchain, if not better. linaro is just a buzzword, nothing more. people add it into their titles for their roms or kernels to make people think that their rom or kernel is special, but it doesnt make a difference in reality. it is just a buzzword.
thanks for the help guys. im sorry if i came off noobish