Android OS Forum banner

[KERNEL] {ADA} *4.1/4.2* ZenSERIES vX *ZenX Walking Tall*

134K views 1K replies 172 participants last post by  Purian23 
#1 · (Edited by Moderator)

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
 
See less See more
1
#2 · (Edited by Moderator)
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.
 
#17 ·
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.
 
#19 ·
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]
 
#34 · (Edited by Moderator)
Here you go. I posted this over in the Affinity thread, before this one went up. It should give you a good idea of what to expect. Check the thread I've linked to for more technical information.


---------------------------------------------------
Ok guys...here are some of my findings, based on testing different governor/scheduler combos. Your results may vary, depending on how you use your device:

*First...do a clean flash (cache and dalvik wipe) to avoid any potential boot issues.

Interactive/sio: a trued and true combo, that's both quick and responsive, and decent on battery.

On demand/ deadline: another old combo, that many people prefer for its low battery consumption.

SavagedZen/CFQ: slightly slower than Interactive/sio, but very smooth, and provides great battery. If you don't care too much about benchmarking, and want a great all-around setup...this may be a good choice. *[Best for battery...by a LOT]

Interactivex/sio: slightly better battery than Interactive/sio, but similar overall performance. *[Fastest combo...does give micro lag at times]

Lulzactive/sio or deadline: choose a scheduler based on how you want your device to perform. Lulzactive is a mix of Interactive and Smartass, so pairing it with sio will give you faster overall performance, while deadline gives a little more smoothness and battery.

Intellidemand/deadline, sio, or CFQ: Intellidemand has some GPU scaling properties to it, that fit perfectly with JB's Project Butter code changes. Mix it with deadline for better battery, sio for speed, or CFQ for a nice balance.

*My personal setup is Intellidemand/CFQ, as I've found it to be the best for me. I get good battery, it's great for gaming (tested with Order and Chaos, Dungeon Defenders and Modern Combat), stays pretty cool, and stays stable.

***Some Tweaks {color and performance} * * *

ROM Toolbox Pro:

(Under systctl tweaks):
vm.dirty_background_ratio = 70
vm.min_free_kbytes = 4096
vm.vfs_cache_pressure = 30
vm.oom_kill_allocating_task = On

(Under SD boost): set to 4096

Franco app color tuning:

Color multipliers: 157, 144, 200
RGB Gama: -4, 0, 4
Trinity's Contrast Interface: -13
OMAP4 Gama Interface: 1.4
Disable CAB: checked

*Again...these are just what works for me. Try them and play around with them if you want. Hope this helps. 

Here is IMO, the best governor/scheduler resource guide in all of my internets! If you want to learn a bit more, check it out.

http://forum.xda-dev...d.php?t=1369817
 
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