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

Search This thread

purian23

Senior Member
Jan 11, 2009
980
1,363
Nexus%20OP.png

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
 
Last edited:

bbedward

Inactive Recognized Developer
Jun 6, 2010
1,892
2,574
Cleveland, OH
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.
 
Last edited:

ommadawn-xda

Senior Member
Jun 5, 2012
102
48
Bari
Realme GT
Hi, just to let you know that, although I guess this was meant for Galaxy Nexus only, I installed it on my Nexus S with latest PA (2.22.1) and I have not experienced any issues so far...

Sent from my Nexus 7 using Tapatalk 2
 

purian23

Senior Member
Jan 11, 2009
980
1,363
Very great feedback so far, thank you all.!! One thing I can assure you is that it is cutting edge of technology & built to withstand it!!! We anticipate all of your feedback to come and thank you for using ZenSERIES :)

Purian23
 
  • Like
Reactions: jjhiza

anoraknophobia

Senior Member
Jun 3, 2010
157
8
Stuttgart
Flashed the Kernel a few hours ago. Performance is great but i already had 3 random reboots so far.
Did a clean install with PA 2.51 Rom.
Kernelsettings were 192-1230 interactivex.
 

purian23

Senior Member
Jan 11, 2009
980
1,363
Ohh no ;( Did you wipe cache and dalvik cache? That should help you to get going. Please let us know if that works!
 

purian23

Senior Member
Jan 11, 2009
980
1,363
Flashed the Kernel a few hours ago. Performance is great but i already had 3 random reboots so far.
Did a clean install with PA 2.51 Rom.
Kernelsettings were 192-1230 interactivex.

Very odd, should be really stable at those settings, if you could move up to 384/1230 and see if it still happens. Thank you for reporting first, we appreciate it!
 

Top Liked Posts

  • There are no posts matching your filters.
  • 112
    Nexus%20OP.png

    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
    29
    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.
    24
    Hey guys,

    Just wanted to thank you all for a great time here with ADA and ZenSERIES. It is time for me to move on from ADA to adhere to my real life situations in my jobs and family. I think we've always had an awesome crowd here and I expect to see you guys around in the forums. I might pop out here at some point later doing another area of development or something cool! The ZenSeries Awesome Developer bbedward will be starting new threads for you all to enjoy in the next version of Zen and releases to come :)

    Thank you all,

    Purian23
    21
    Kernel Update!!!

    Nexus%20OP%20Update.png

    Introducing
    v3.0.55-ZenSERIES v12 Kernel
    *Zeneractive Lives*
    Fast, Smooth & Battery Friendly

    Unified Kernel for Toro/Toroplus/Maguro

    ada_0000_changelog.png

    Code:
    [B]ZenSERIES_v12[/B]
    - Updated to v3.0.55
    - Rebased the whole kernel tree to clean up
    - Updated bcmdhd+ipv4 with some upstream fixes/wakelock related
    - Disabled merging on deadline and no-op
    - Added in some more TCP congestion schedulers (cubic still default)
    - Some misc. updates - More SoD Actions taken
    - Replaced interactiveX with "Zeneractive." (documentation: http://pastebin.com/UrkEke8k)
     - Interactive-based governor with "live" CPU hot plugging.
     - Behavior on Zeneractive with Great Battery:
     - If CPU load is <= unplug_load[cpu] for a given CPU for time = unplug_delay, that CPU will be removed (if online)
     - If CPU load is > unplug_load[cpu] for a given CPU for time = insert_delay, that CPU will be inserted (if offline)
     - Tunables: unplug_load_cpu1 (default: 25%), unplug_load_cpu2 (default: 60%), unplug_load_cpu3 
    - Zeneractive (default : 75%), unplug_delay (default: 5s), insert_delay (default: 30ms)

    ZenSERIES Kernel v12 4.2
    ZenSERIES Kernel v12 4.1
    Main Download
    Enjoy!


    See OP for further information!
    Thank you
    Android Developer Alliance
    19
    Ohhhh nice could you give me a link :D
    I want to flash xylon b3 and want not to flash a old 12 kernel ;)
    .... just a nice try...

    ... And what's your best saving battery settings in trickster?

    Craxx;)

    Send from my Galaxy Nexus with Tapatalk :)

    v12 is not available yet ;) stay tuned as it should be very soon.

    Some more zeneractive info, its ready for release and has been thoroughly improved since v12 RC1, with revamped hotplugging logic.

    Tunables over interactive:
    - unplug_load_cpu1/2/3 (we only care about unplug_load_cpu1 on the GNex)
    - insert_delay (default: 30 milliseconds)
    - unplug_delay (default: 5 seconds)
    - suspend_frequency (default: 729.6MHz) - our frequency target when suspending. (wake frequency target is always hispeed_freq)

    So the frequency scaling is exactly the same as interactive.

    The hotplugging algo works like this:
    work done on a realtime thread.
    for any/every CPU, lets say CPU #1
    - We compare CPU load to unplug_load_cpu1
    - If CPU load is <= unplug_load_cpu1, we increment how long its been since the last time CPU load was <= unplug_load_cpu1, and we completely forget about the last time the CPU load was > unplug_load (reset that timer)
    - If CPU load is > unplug_load_cpu1, we increment how long its been since the last time CPU load was > unplug_load_cpu1, and we completely forget about the last time the CPU load was <= unplug_load (reset the timer)
    - When CPU load has been <= unplug_load_cpu1 for unplug_delay (5s by default), we will remove CPU 1 (if it is online)
    - When CPU load has been > unplug_load_cpu1 for insert_delay (30ms by default), we will add CPU 1 (if it is offline)
    - All auxillary CPUs are removed on suspend, and the hotplug thread does not perform any logic
    - On wake, all CPUs are inserted and we attempt to ramp up every CPU to the hispeed_frequency.