[KERNEL][AOSP-3.4.y][AXDEV][d2] Harkness - 05/01/14

Search This thread

Synthetic.Nightmare

Inactive Recognized Developer
Mar 29, 2011
952
1,211
Sorry folks, I was (and still am, somewhat) on a bit of a hiatus from android development and the XDA Community. Part of me felt like I learned too much in too little time (I released my first source-built rom on April of last year [with no prior experience] to give you an idea as to how long I've been taking development [somewhat] seriously) and the latter was due to me being sick of certain ideals that were condoned in parts of the XDA forums.
I plan on continuing development soon, but I've aso got a bit of cleaning to do with the current source (locally). After that, I will see to reviewing and merging in CM's changes.
I'm hoping to get back to everything sooner rather than later. :good:
 

matrixzone

Senior Member
Mar 19, 2012
3,534
3,584
Sorry folks, I was (and still am, somewhat) on a bit of a hiatus from android development and the XDA Community. Part of me felt like I learned too much in too little time (I released my first source-built rom on April of last year [with no prior experience] to give you an idea as to how long I've been taking development [somewhat] seriously) and the latter was due to me being sick of certain ideals that were condoned in parts of the XDA forums.
I plan on continuing development soon, but I've aso got a bit of cleaning to do with the current source (locally). After that, I will see to reviewing and merging in CM's changes.
I'm hoping to get back to everything sooner rather than later. :good:

Thanks for the update. Take your own time :p at the same time waiting for the next release :good:
 

lostboykev

Member
Nov 12, 2009
35
24
Great job on this kernel. My 3DMark score overall has jumped up by 200 points. Lock screen wakeup is much quicker, fluidness in launcher. Less misc errors and artifacts. I have the 6/7 version. Please keep it going! This has been the only kernel to satisfy my battery, performance and stability requirements.

Do you have a way to donate for your efforts?
 

matrixzone

Senior Member
Mar 19, 2012
3,534
3,584
Great job on this kernel. My 3DMark score overall has jumped up by 200 points. Lock screen wakeup is much quicker, fluidness in launcher. Less misc errors and artifacts. I have the 6/7 version. Please keep it going! This has been the only kernel to satisfy my battery, performance and stability requirements.

Do you have a way to donate for your efforts?

Paypal id is mentioned in his profile:thumbup:

Sent from my SAMSUNG-SGH-I747 using xda app-developers app
 
  • Like
Reactions: Synthetic.Nightmare

Synthetic.Nightmare

Inactive Recognized Developer
Mar 29, 2011
952
1,211
I thought I'd leave a little test kernel here for ya.
I haven't run it for very long; and due to my lack of sleep all this last week, I am just not feeling like weeding out a changelog :/ (esp. since I rebased onto CM, with some parts removed). Though, I'll try and get one for everyone either later tonight or early tomorrow. In the meantime I just kinda quickly came up with a small list of changes:
- rebase about 90% onto cm-10.1 (to try rooting out a buggy commit)
- merge edft branch from sched-deadline (edf adjustments to rt)
- updates to ondemand
- include zen-tuning for interactivity
- more (full changelog to be posted soon, view source in the meantime to review changes)
***TO-DO***
- tune auto-hotplug, ondemand, maybe more
- re-add SLQB (?) [req. further testing]​
And I've also rebased my (important) topic branches onto cm, so anyone using the d2 kernel as a base for their kernel can (somewhat) easily merge in sched-dl and misc changes. Might run into a few merge conflicts when combining topic branches... but those conflicts aren't anything major (and my jb-mr1 source can be used as a reference)

Download: http://d-h.st/SuV
Source [again] (for anyone interested): https://github.com/SyNtheticNightmar3/android_kernel_samsung_d2

Enjoy. Have an awesome weekend folks. Mine is going to be spent trying to catch up on sleep :p
 
Last edited:

matrixzone

Senior Member
Mar 19, 2012
3,534
3,584
What will be the best settings(gov,scheduler) for getting the max battery?

Sent from my SAMSUNG-SGH-I747 using xda app-developers app
 

lostboykev

Member
Nov 12, 2009
35
24
I thought I'd leave a little test kernel here for ya.
I haven't run it for very long; and due to my lack of sleep all this last week, I am just not feeling like weeding out a changelog :/ (esp. since I rebased onto CM, with some parts removed). Though, I'll try and get one for everyone either later tonight or early tomorrow. In the meantime I just kinda quickly came up with a small list of changes:

Enjoy. Have an awesome weekend folks. Mine is going to be spent trying to catch up on sleep :p

Just flashed your test kernel. Nothing to report yet. User experience is still the same. I will test is out for a few days as report back. Nothing technical just my everyday experience with it and problems.
 
  • Like
Reactions: Synthetic.Nightmare

Synthetic.Nightmare

Inactive Recognized Developer
Mar 29, 2011
952
1,211
My God I just googed. Thanks!

Sent from my SGH-I747 using xda premium

lol :highfive:

What will be the best settings(gov,scheduler) for getting the max battery?

Sent from my SAMSUNG-SGH-I747 using xda app-developers app

I've been messing with ondemand recently and have created a powerHAL to work along with it; which controls powersave bias between screen on and off (battery life has shown some improvement with little impact on performance; mainly in benchmarking, but I only care so much about benchmarks). I'll post a zip for that whenever I get another build out.



Just flashed your test kernel. Nothing to report yet. User experience is still the same. I will test is out for a few days as report back. Nothing technical just my everyday experience with it and problems.

Works for me, since most of it was just a rebase onto CM anyway. So long as nothing is broken.

Oh and here is that changelog I never came up with :( ...
- Merge branch 'rebase-onto-edft' into jb-mr1 [earliest deadline first adjustments for sched-rt]

- cpufreq: ondemand: Disable freq sync feature in store_powersave_bias

- cpufreq: ondemand: Fix locking issue in store_powersave_bias

- cpufreq: ondemand: change freq sync code to use per-CPU kthreads

- msm: Synchronize CPU frequency on thread migration

- zen-tune: Implement zen-tune ([more] simplified version)
*VM dirty ratio: 50
*VM dirty background ratio: 20
*Ondemand downsample factor: 10
*Scheduling latency: 3 ms
*Minimal granularity: 0.3 ms
*Wakeup granularity: 0.5 ms
*CPU migration cost: 0.25 ms
*Bandwidth slice size: 3 ms

- arm: compressed: define CPU architecture

- mm: removed SLQB

- auto_hotplug: remove some tunings

- remove some -rt patches​
 
Last edited:
  • Like
Reactions: matrixzone

Synthetic.Nightmare

Inactive Recognized Developer
Mar 29, 2011
952
1,211
I know it's been a while since I posted a release (after the test) but thats only because I wanted to make sure everything was in tip-top shape and with the amount of adjustments made between then and now, I wanted to have something that was working nicely before releasing. I don't want to say I'll do nightlies, weeklies or even monthlies, due to the fact that I try testing things as intensively as I can and because kernels can take some time before they "settle." But I do want to try releasing more often.
As stated, I've pulled in and made a couple of changes since the test, and there are a few I wanted to touch on and possibly ask your opinion about...

1. I have included the tripndroid iosched by TripNRaVeR. It's based on noop, deadline and vr and meant to have minimal overhead. I would like to know if it would be preferred in place of zen.

2. Harkness is now being compiled using -O2 with Sourcery CodeBench Lite's gcc-4.7.3 toolchain (compiles -O2 cleanly and at the speed of the gcc-4.8 toolchain I was testing out). I went with this one because a post by ezekeel some time ago debunking the effect of optimized toolchains in benchmarking, it seemed this one actually made somewhat of a difference. Though, I have also read that previous revisions of this toolchain can be buggy with neon if I remember right, so I'd like to see if there are any problems with this revision of the toolchain (but after a few days, I've yet to see anything wrong on my current rom).

3. Off this last charge cycle, I've gotten ~20.5 hours with about 5 hours and 16 minutes screen time (screenies at request; they're on my device). Which is something my d2tmo hasn't done before. At least not in recent memory. But that is not the point... I had forgotten to turn off proprietary mpdecision (and raise my auto_hotplug settings for testing), so I'm thinking it's working well enough to do away with auto_hotplug, but I'd like to know opinions on the current implimentation and how it works for you, any preferred settings and whatnot would also be appreciated; that way if it does stay, I can have an idea on some tunings that work (because I can't seem to find a satisfactory one).

Unfortunately, the ondemand/powerHAL combo will have to wait until I get to test some things, but this last cycle worked well with CM's defaults, but the good news is, I've gotten this source to compile with ZER0 warnings. :cool: remove-warnings branch has been added to OP if any dev is interested in getting rid of some useless common warnings on cm source.

Ack. Too many words for a forum post. I think that's the important stuff I wanted to cover lol.

Changelog: http://pastebin.com/xMvAXbmQ
07/24 Download: http://d-h.st/Pmr
 
Last edited:

phoenix2217

Senior Member
Dec 21, 2010
1,068
249
18518
I know it's been a while since I posted a release (after the test) but thats only because I wanted to make sure everything was in tip-top shape and with the amount of adjustments made between then and now, I wanted to have something that was working nicely before releasing. I don't want to say I'll do nightlies, weeklies or even monthlies, due to the fact that I try testing things as intensively as I can and because kernels can take some time before they "settle." But I do want to try releasing more often.
As stated, I've pulled in and made a couple of changes since the test, and there are a few I wanted to touch on and possibly ask your opinion about...

1. I have included the tripndroid iosched by TripNRaVeR. It's based on noop, deadline and vr and meant to have minimal overhead. I would like to know if it would be preferred in place of zen.

2. Harkness is now being compiled using -O2 with Sourcery CodeBench Lite's gcc-4.7.3 toolchain (compiles -O2 cleanly and at the speed of the gcc-4.8 toolchain I was testing out). I went with this one because a post by ezekeel some time ago debunking the effect of optimized toolchains in benchmarking, it seemed this one actually made somewhat of a difference. Though, I have also read that previous revisions of this toolchain can be buggy with neon if I remember right, so I'd like to see if there are any problems with this revision of the toolchain (but after a few days, I've yet to see anything wrong on my current rom).

3. Off this last charge cycle, I've gotten ~20.5 hours with about 5 hours and 16 minutes screen time (screenies at request; they're on my device). Which is something my d2tmo hasn't done before. At least not in recent memory. But that is not the point... I had forgotten to turn off proprietary mpdecision (and raise my auto_hotplug settings for testing), so I'm thinking it's working well enough to do away with auto_hotplug, but I'd like to know opinions on the current implimentation and how it works for you, any preferred settings and whatnot would also be appreciated; that way if it does stay, I can have an idea on some tunings that work (because I can't seem to find a satisfactory one).

Unfortunately, the ondemand/powerHAL combo will have to wait until I get to test some things, but this last cycle worked well with CM's defaults, but the good news is, I've gotten this source to compile with ZER0 warnings. :cool: remove-warnings branch has been added to OP if any dev is interested in getting rid of some useless common warnings on cm source.

Ack. Too many words for a forum post. I think that's the important stuff I wanted to cover lol.

Changelog: http://pastebin.com/xMvAXbmQ
07/24 Download: http://d-h.st/Pmr


I didn't even notice the new IOsched. I'll try it out today. I've been running it since yesterday with zero issues. Very smooth, very good battery life.

Just for a basis, I use the Carbon nightlies.
 
  • Like
Reactions: Synthetic.Nightmare

neim81094

Senior Member
Nov 8, 2012
279
36
Brooklyn
My current kernel, let's hope the latest update fixed the bugs I have been seeing :D

Sent from my SGH-T999 using xda app-developers app
 

phoenix2217

Senior Member
Dec 21, 2010
1,068
249
18518
Been running this now for 24 hours with the new IO sched. Gotta say, pretty nice. No noticeable battery drain and everything is smooth. :fingers-crossed:
 

kiden

Senior Member
Feb 3, 2010
170
88
Chicago
So I totally forgot to report back. And now there is a new one! Been running it for a while and no issues yet! Thank you!
 

Top Liked Posts

  • There are no posts matching your filters.
  • 25

    ...AX Developers Present...
    ...In association with Team Inferno...
    axDev Harkness
    "Self determination is NOT a malfunction" -Harkness (Android A3-21)


    This kernel is experimental. All patches used, source code, etc. can be found here with as many of the original authors intact as possible.
    ***ONLY RECENT (aka inline with CMs display drivers) AOSP-BASED ROMS SUPPORTED***

    FEATURES:
    - based off of Cyanogenmod's 3.4.y kernel
    - compiled using Sourcery CodeBench Lite GCC 4.7 toolchain (-Os)
    - floating-point & graphite loop optimizations
    - cleaned up some modules and debugging
    - Tweaked GPIO debounce timing [Increased vol. long press]
    - Increased touchscreen sensitivity
    - dkp notification/backlight LED fade animations (DecimalMan)
    - faux sound support
    - patches from a plethora of sources (including franciscofranco, WillDeacon, ConKolihas, etc.)
    - fast charge capable (imoseyon)
    - UV capable (faux123)
    - full sched-deadline implementation (jlelli)
    - semaphore n4's conservative & ondemand driver (stratosk)
    - Power efficient workqueues (Linaro)
    - Plenty of backports from mainline [sched, cpuidle, random, smp, etc.] (Linux)
    - asm-generic rwsem (Will Deacon)
    - Imports from Motorola's msm kernel source:

    * always update vfp_current_hw_state when forcing reloading
    * fixup to allow sched to play nice with CPU_HOTPLUG
    * Krait memutils
    * acpuclock-krait: init to max speed (improve boot time)
    * lmk/compaction: updates to allow improved/stricter memory management

    - I'll add more as I remember​

    BUG REPORTS:
    Please include a kmsg/dmesg to any bug reports: http://code.google.com/p/tegraowners-ics-rom/wiki/How_to_get_logs
    If you you are unable to do so for whatever reason, try to use as much detail as possible and give me a way to replicate it, so that I may attempt to log it. Thanks!

    NOTES:
    - Reserved for notes about bugs.
    - Cleared since we seem to be golden with trickstermod and I have yet to have a recent cm build fail on init. Let me know if you find anything.

    SCHED_DEADLINE:

    Not to be confused with the iosched deadline, Sched_deadline is a scheduling class that implements a real-time CPU scheduling algorithm; EDF (Earliest Deadline First), augmented with a bandwidth isolation mechanism (called Constant Bandwidth Server, CBS) that makes it possible to isolate the behaviour of tasks between each other. SCHED_DEADLINE allows the CPU to reserve a portion of the CPU time to a specific application very accurately. A key feature is that it ensures "temporal isolation", which means that the temporal behavior of each task (i.e., its ability to meet its deadlines) is not affected by the behavior of any other task in the system. In other words, even if a task misbehaves, it is not able to exploit larger execution times than the amount it has been allocated. When a task tries to execute more than its budget, it is slowed down, by stopping it until the time instant of its next deadline. When, at that time, it is made runnable again, its budget is refilled and a new deadline is computed.


    POWER EFFICIENT WORKQUEUES:

    With per-cpu workqueues, the scheduler considers a CPU idle if it doesn't have any task to execute and tries to keep idle cores idle to conserve power; however, for example, a per-cpu work item scheduled from an interrupt handler on an idle CPU will force the scheduler to excute the work item on that CPU breaking the idleness. Power efficient workqueues are allowed to be unbound, meaning they are not forced to queue up on what could be an idle CPU; instead, the scheduler allows work to be rescheduled on a core that is already awake.


    SEMAPHORE ONDEMAND TUNABLES:

    touch_load: the simulated load when there is a touch on screen (default 75)

    touch_load_threshold: over this load the touch_load will be applied (default 10)

    touch_load_duration: the duration of the simulated load in msec (default 1100)


    VOLTAGE TABLES/BINNING:

    What CPU do you have? Nominal, Fast :)...or Slow:(

    The phones with the lower default voltage values use the "fast" frequency table, consider yourself lucky. This explains why some can't UV as much as others since they are starting with lower mV's to start. These are built in factory tolerances that depend upon the binning of your chip. Hopefully folks don't go freaking out because they have a nominal chip like I do. It's probably good for a dev to have a nominal chip so we can better honor the limits.

    http://en.wikipedia.org/wiki/Product_binning

    How do I tell what I have?
    If you boot up your phone fresh and look at the dmesg output (kernel log) while the messages are still there, you will find one of the following output messages where it selects it's frequency plan depending on the binning of the chip.

    commandline:
    adb shell dmesg | grep PVS

    (acpuclk-krait in our kernel defines PVS as id numbers)

    acpuclk-8960: ACPU PVS: 0 = Slow
    -or-
    acpuclk-8960: ACPU PVS: 1 = Nominal
    -or-
    acpuclk-8960: ACPU PVS: 3 = Fast


    - thanks to _motley for this awesome write-up on his kernel/kernel features... and for providing explicit detail on his works

    A Note for Developers:
    CODEBENCH COMPILE CACHING:

    Ccache is commonly used to reduce compile times for C-related files. CodeBench's toolchains utilize their very own compile caching that works EXTREMELY well. You MUST be on at least the 5-23 version of CodeBench (CodeBench Lite can be found here). The related patch for using this feature will be posted below. Examples of use are in the commit message.

    Basic CS cache patch

    Please pull request any improvements/post discussion.


    I'll add more info about key features as I work along.

    DOWNLOADS:
    - -
    https://code.google.com/p/harkness-d2/
    !! NOTE: this OP no longer reflects what this kernel is. See the URL above for the latest. !!

    CREDITS/THANKS:
    Cyanogenmod
    MentorGraphics
    Juri Lelli (and everyone else in the SCHED_DEADLINE project)
    MotorolaMobilityLLC
    existz
    TripNRaVeR (tripndroid)
    Will Deacon (ARM)
    stratosk
    franciscofranco
    decimalman
    _motley
    Con Kolihas
    imoseyon
    showp1984
    faux123
    f1vefour
    ryuinferno
    xcstacy
    Linaro
    Eli Billauer
    kerneldedup.org
    Bethesda
    and countless others (may they be remembered on github)
    8
    anybody ran this lately on latest nightlies?
    Should be fine, there haven't been many changes to the cm kernel.

    Although, I uploaded another build today. :p

    Direct URL -
    http://dl.bintray.com/syntheticnightmar3/rivet/Harkness-Kernel-d2-2014-10-11.zip

    Changelog:
    - Merge cm-11.0
    - Fix-up memutils (import newer patch from moto & clean up)
    - Import pskm (Anon-Page KSM: https://code.google.com/p/pksm/)
    - ARM updates for branch predictor maintenance

    Let me know if there's any issues with it (pksm might need some tuning). Same deal as last time, just built and uploaded (but tested in similar builds). As long as it uploaded alright, it should be fine.
    7
    I know it's been a while since I posted a release (after the test) but thats only because I wanted to make sure everything was in tip-top shape and with the amount of adjustments made between then and now, I wanted to have something that was working nicely before releasing. I don't want to say I'll do nightlies, weeklies or even monthlies, due to the fact that I try testing things as intensively as I can and because kernels can take some time before they "settle." But I do want to try releasing more often.
    As stated, I've pulled in and made a couple of changes since the test, and there are a few I wanted to touch on and possibly ask your opinion about...

    1. I have included the tripndroid iosched by TripNRaVeR. It's based on noop, deadline and vr and meant to have minimal overhead. I would like to know if it would be preferred in place of zen.

    2. Harkness is now being compiled using -O2 with Sourcery CodeBench Lite's gcc-4.7.3 toolchain (compiles -O2 cleanly and at the speed of the gcc-4.8 toolchain I was testing out). I went with this one because a post by ezekeel some time ago debunking the effect of optimized toolchains in benchmarking, it seemed this one actually made somewhat of a difference. Though, I have also read that previous revisions of this toolchain can be buggy with neon if I remember right, so I'd like to see if there are any problems with this revision of the toolchain (but after a few days, I've yet to see anything wrong on my current rom).

    3. Off this last charge cycle, I've gotten ~20.5 hours with about 5 hours and 16 minutes screen time (screenies at request; they're on my device). Which is something my d2tmo hasn't done before. At least not in recent memory. But that is not the point... I had forgotten to turn off proprietary mpdecision (and raise my auto_hotplug settings for testing), so I'm thinking it's working well enough to do away with auto_hotplug, but I'd like to know opinions on the current implimentation and how it works for you, any preferred settings and whatnot would also be appreciated; that way if it does stay, I can have an idea on some tunings that work (because I can't seem to find a satisfactory one).

    Unfortunately, the ondemand/powerHAL combo will have to wait until I get to test some things, but this last cycle worked well with CM's defaults, but the good news is, I've gotten this source to compile with ZER0 warnings. :cool: remove-warnings branch has been added to OP if any dev is interested in getting rid of some useless common warnings on cm source.

    Ack. Too many words for a forum post. I think that's the important stuff I wanted to cover lol.

    Changelog: http://pastebin.com/xMvAXbmQ
    07/24 Download: http://d-h.st/Pmr
    7
    Been testing this and wanted to push sooner, but didn't get the chance to til now (I also wanted to clean the commits up some more, but everything seems to be working on my d2tmo, so screw it).

    05-01-2014 Download -
    GooManager

    Changelog:
    - Merged in CM
    - Built with CodeSourcery gcc-4.8 (will update script once I get my new CrunchBang setup finalized [so long, Mint])
    - Imported some changes to our display/video drivers from the Sprint KK update

    I'll fix this up if I need to tomorrow. Gonna knock out now and test the latest changes with a full charge tomorrow.
    6
    Finally got around to installing kitkat on my gf's d2att and had the same problem on a clean install @jukiewalsh.
    I had to install my rom and gapps first, let it boot, then reboot and install the kernel. CM11 on our devices is buggy on init and I'm thinking that may just be a part of it. Afterwards, it worked as expected.
    So now that I have 2 devices to test on with varying usecases, I can find out about things I broke sooner.
    And while out of town, I found out my commit for touch_load caused some deep sleep trouble (on occasion, it would get cpu0 as offline and set it that way while the ondemand driver checked the cpu). So I've got a quick update that will likely fix the issue:

    12-27-2013 Downloads:

    goo.im

    dev-host

    Changelog:
    - ondemand: only account for touch_load when cpu0 is online
    - Update led touchkey animation to current dkp-4.4 (just because I was here doing things already)