Android OS Forum banner
1 - 20 of 1068 Posts

·
Follow the Android
Joined
·
314 Posts

Introducing
ZenSERIES Kernel
*ZenX Walking Tall*
Fast, Smooth & Battery Friendly

Unified Kernel for Toro/Toroplus/Maguro


The All New OP's will be maintained by ADA's Kernel Dev bbedward.!!!

To better serve you;
This here as a placeholder for your device redirecting to the main kernel support thread.


Find ZenSERIES Kernel Thread here!!!

Thank you and Enjoy!
Android Developer Alliance
 

·
Registered
Joined
·
48 Posts
FAQ - Will be updated as needed.
Q: CPU Frequency Governor, I/O schedulers, what?
A: Here's a good resource that explains a lot about the topic in general and schedulers: http://forum.xda-developers.com/showthread.php?t=1369817

Q: I want different colors, how do I do it?
A: You can use an app such as Trickster MOD, Trinity, Franco, or Glados Control to change these. I prefer to keep them default on my builds because preference varies. (For reference, trinity's default colors are R: 135 G: 135 B: 214, Gamma offset 0/0/0 (I think)

Q: Kernel is randomly rebooting, how can I help?
A: After a reboot, pull /proc/last_kmsg from the device and send it my way.

Q: What I/O scheduler should I use?
A: I haven't really found any real-world difference between any of them. I personally prefer the simpler algorithms of Zen/SIO.

Q: What CPU frequency governor should I use?
A: Entirely up to you. I tend to favor interactive because it's google's governor.

Q: Do all these extra I/O schedulers and cpu frequency governors impact performance or stability?
A: No. I like to keep as many as people will use. If 1 person prefers the conservative governor it'll stay in. There is minimal->no overhead from including extra I/O and/or cpu frequency governors. Therefore, performance+stability will not be affected in the slightest. Choose the one you like, if not sure the default settings are a safe bet.

Q: Why did you create ZenSERIES?
A: It's pretty fun to do, and it's going to make a great pairing with AffinitySERIES, and hopefully several other roms as well.

Q: Do you support any other devices?
A: Working on several others.

Q: What is this "Zen Info" sysfs interface?
A: Probably nothing you care about unless you're a developer looking to do something special with zen. Otherwise, it doesn't affect you and it's for me.

Q: What is this Aaron Carol stuff you added (V(r ), no-op changes, fifo (I wrote a detailed answer already, so wanted to include it in FAQ)
A:
1.) V(R ) is similar to deadline (uses deadlines for fairness). Basically, requests are based on on the distance from the last request/I.E: the next closest request comes first (with penalty of rev_penalty). Naturally, we don't care about the distance from the last request because we're using flash memory (in our case, handling the closest request is nothing but overhead since there is no travel delay) so it doesn't matter where the next request is. I'd say in a nutshell it would be a higher thoroughput/higher latency version of deadline in a typical desktop environment. On our phones, not sure where it would fall. (I removed some unnecessary parts of the algorithm, like choosing closest request/changing head direction, etc.) You may say "Oh, why would you add an I/O scheduler that handles requests like that?" Well, it's not the only one. Deadline/CFQ/BFQ will all sort requests. But the difference between them, in my experience, is usually negligible for real-world tests.

2.) FIFO: Ok, so no-op stands for "no operation". Essentially that means handle requests in order, don't sort them, don't merge them, don't do anything except handle the next request in line. In reality, it actually does some sorting (sorts dispatches, and some requests i think). FIFO is a true "no-op" scheduler. Doesn't do anything, strictly FCFS.
* e.g. We could have 3 requests in the queue. the first one could be very small, second one could be astronomically large, third one can be extremely small. Some schedulers may say, lets do #3 before #2 because it is right next to where we're at and it's very short. Some schedulers may say, lets combine #3 and #2 to make it 1 large request. Fifo doesn't do any of that, it goes in order. Literally first in , first out.

3.) No-op: No-op already exists in the kernel obviously, now it does a bit more stuff. Like I said above, no-op isn't entirely no-op. I have a patch from AC that makes no-op do full merging and sorting. Meaning, it actually will merge some requests if applicable and sort them based on things like priority, size, distance, etc. Other change to no-op is that dispatches are all back-inserted. Meaning added to the back of a stack. Normally no-op sorts dispatches.

Q: What is the zen I/O scheduler?
A: Well, the question that was asked above led me to an analysis of V(R ), deadline, and some others. I already knew, but realized "this is the main feature of V(R), but wait it has no benefit to us smartphone users." So I thought about adjusting the way V(R ) handled requests and how it dispatched them (I chose V(R ) because i'd rather not tinker with a scheduler thats official and widely supported). Then I was looking over it, and realized I might as well just write a new one I don't need any of this stuff. So I came up with something awfully similar to SIO, although its a bit simpler than SIO (closer to no-op) and works just slightly different.
- It's an FCFS (First come, first serve) based algorithm. It's not strictly FIFO. It does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones. Other than that, pretty much the same as no-op.
 

·
Follow the Android
Joined
·
314 Posts
Discussion Starter · #12 ·
Was just checking out ROM also. Very intrigued when its updated to latest version. Not trying to sound like ass.

Sent from my Galaxy Nexus using Tapatalk 2
You are fine, it is certainly on its way.! 4.2 we now know is still Jelly Bean, but source is not yet available, so we'll continue to rebase on 4.1.2 and plan to get a nice update out!

Thank you,

Purian23
 

·
Follow the Android
Joined
·
314 Posts
Discussion Starter · #14 ·
Been running this since Friday night at 1305/384 Interactive ... loving it so far! franco.Kernel Updater app from Play Store works perfectly with this one.
Color set at 135/135/214 , Contrast -8, and Gamma 1.2 and it is beautiful thing!! Thanks ADA
Glad to hear it is running well for you! Thanks for the report Freedom :)
 

·
Android Beginner
Joined
·
91 Posts
I'm not sure if that's what caused it but I had the black screen with those settings. The 230 was the only thing I had changed. It was a fresh install from a day earlier of the ROM with no mods. I installed the kernel, changed to 230, and it ran fine the rest of the evening. I left it on the charger overnight and when I went to unlock it in the morning it wouldn't. Had to pull the battery.
 

·
Registered
Joined
·
400 Posts

·
Follow the Android
Joined
·
314 Posts
Discussion Starter · #19 ·
I'm not sure if that's what caused it but I had the black screen with those settings. The 230 was the only thing I had changed. It was a fresh install from a day earlier of the ROM with no mods. I installed the kernel, changed to 230, and it ran fine the rest of the evening. I left it on the charger overnight and when I went to unlock it in the morning it wouldn't. Had to pull the battery.
Hey guys, this is a quote from our Kernel Dev bbedward in our other forum that pertains to this.

[background=rgb(233, 233, 233)]"I believe there are issues, perhaps voltage/SR related, with 192/230MHz frequencies causing sporadic reboots for some people. Looking into that, if you're having issues revert to 384, if not keep on rolling [/background]


[background=rgb(233, 233, 233)]If you get odd behavior please try to shoot over a log, if you get a reboot try to send over /proc/last_kmsg "[/background]
 

·
FuSiOn
Joined
·
134 Posts
Hey guys, this is a quote from our Kernel Dev bbedward in our other forum that pertains to this.

[background=rgb(233, 233, 233)]"I believe there are issues, perhaps voltage/SR related, with 192/230MHz frequencies causing sporadic reboots for some people. Looking into that, if you're having issues revert to 384, if not keep on rolling [/background]


[background=rgb(233, 233, 233)]If you get odd behavior please try to shoot over a log, if you get a reboot try to send over /proc/last_kmsg "[/background]
Yup, I get reboots on anything under 320. Where should I send the kmsg?

Edit: here's a pastebin of it: http://pastebin.com/KPTfSUSE

If I need to send it elsewhere, just let me know.

Sent from my Galaxy Nexus using Tapatalk 2
 
1 - 20 of 1068 Posts
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top