yashsingh1/xdaforums huggingface dataset:
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
- Maple IO scheduler is added back (next release)

- I can now easily keep up to date with WireGuard - The dev helped me get my kernel sources setup for it. great stuff

- I'm working on some cleanups too

- I also have a few missing bits and cherry-picks on the list of todos, but they will trickle in

Next, I'm going to be familiarizing myself betterwith the userspace changes in 8.1 and start looking at ways to improve battery. and hopefully get Dynamic Stune working again (assuming that I should / would be beneficial to early to tell wtih 8.1 being so new ).
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Nil253259:
Just upgraded to 8.1. yet to flash your kernel. But 8.1 is so smooth and responsive. I'm definately sure this is not placebo. Formatting /system partition improves things. But I'm talking about real performance boost here. What about others? Excited to try this Kernel tonight
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
It's not a placebo ~ 8.1 is a substantial update... Scheduling /prioritzation of threads/tasks is better,. The Stock Binder is much better than the 8.0 stock kernel (but I still replace it with binder_rt), driver fixes, configuration changes, etc, etc....

what about other what?

Yup, let me know how it goes. I'm going to push another update shortly - but it will be the same link /build (just config init rc changes).
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Soo...

while the download remains the same; Technically, there are changes today... Maple IO scheduler and a few other commits are in there, and I've changed around my init rc ~ Just trying to get things a bit better setup for 8.1, add-in/change a few bits here and there.

EDIT:

Mac Randomization is Disabled by default for those who use Mac filtering on their networks.

To enable Mac Randomization;

/proc/sys/dev/cnss/randomize_mac

0 = OFF

1 = ON

You'll need to add a "user stting" to enable (and/or disable) this setting in EXKM. ~ Unfortunately, it doesn't look like EXKM has custom controls like Kernel Aduitor (I wish it did), so you may need two setting to manage on / off... Obviously, Kernel aduitor can do this by creating a custom control....

commandline way to set would be;

echo 1 > /proc/sys/dev/cnss/randomize_mac (to turn on)

or in an init script;

write /proc/sys/dev/cnss/randomize_mac 1
[Google Pixel ROMs, Kernels, Recoveries, & Other De] siheals:
Well, everything is running perfectly. I can't believe we have a custom kernel so soon. Thank you very much.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Thanks, siheals!

LOL. To be honest; I'm a little surprised that I've been able to get my kernel working so quickly too; I expected a lot more pain. There was a lot of code/commits to move over && while it happened quickly; it's been a crap ton of work.... I also expected more regressions and breakage - but it's been minimal, aside from some initial stuff - before I even flashed or tested the kernel (all compilation stuff).... and I still will need to work on improving things..

~ it is stable and working very well for me too, but there is still room for improvement; in both performance and battery life. ~ Switching over to PowerHal has caused a bit of a change and I still need to really evaluate it. But I'll iron out battery life - just might take a couple of days.... (plus, read next post!)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Interesting stuff (potentially for the next build);

- performance enhancements

- battery saving enhancements

I think I've found a few tweaks that are suitable to leverage on 8.1 + my kernel.... My initial testing (just performance based, using YEBIS egl 3.1 Demo (Play Store)

Without changes;

average FPS = 50+ to 60+ fps

peak FPS = 70+ fps (low-to-mid)

With changes;

average FPS = 60+ to 80+ fps

peak FPS = 91fps

* Interactivity is significantly improved with teh changes though... && you don't even need to run tests to see / feel the difference.

The changes aren't doable (at least not fully) on the Stock Kernel ~ It requires SchedUtil and never EAS / scheduling code. So it's a good thing that my kernel is rocking all of this stuff.

I'll need a day to sit on these particular changes - but based on documentation; it should also help improve battery life. We'll see.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Horgar:
Not really had access to a pc until the last couple of days and have been distracted with family issues but I'm now on 8.1 rooted with magisk and with elementalx kernel and TWRP. It was just the set up available when I upgraded to 8.1. But I plan to flash your 8.1 kernel tomorrow. Will let you know. Thanks again for your work. ?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] グリッチ:
Flashing a4a8f03 now, will report after a day. Or if I run into anything (which I doubt) then sooner. I noticed you made separate builds for marlin and sailfish. I always thought they shared the same kernels (at least that's how kernel devs released them), are there any device specific tweaks you did to them?

EDIT: It has been two days, and results are still the same, no stutters, no lag, no FCs, everything is great! I am really looking forward to when you can actually prioritize saving battery, then this kernel will be truly king!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
cool. ya, do that. let me know how it goes...

they are, in fact, the same... but they were slightly different at one point during Oreo 8.0 cycle... so; I am just continuing to keep them as two zips, labelled differently - in case, something like that crops up again...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] matt99017d:
what am i missing here? I was on stock 8.1.0 I did the bootable twrp and then flashed the zip with success. when it reboots it'll go to the dead android fella. So i flashed the stock boot image so the phone works and tried again with the same results. Tell me I'm missing something that is not simple. although i hope it is!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Hey matt,

give me 10-15min and I'll have a zip for you to test, ok?

I think I overlooked a change for unrooted phones ~ just going to make it now and give it a test; then I'll post a zip...

I assume you aren't installing root (magisk or supersu), correct?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] matt99017d:
Yes sir. That is correct. And thanks!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Hey matt,

i PM'd you.... I have to work out the compatibility issue with non-rooted devices in AnyKernel2. The gist is for now; if you want to use my kernel, you will require root; I suggest using magisk....

I'll try and get this sorted out - but it probably won't happen for a day or two... It's one of those things where I don't do a ton of compatibility testing with setups I don't use (ie: non-root or even SuperSU to a lesser degree), so I don't always see when something like that isn't working right away...

I'm going to add a note on the OP for now, regarding non-root issue.

I'll get it sorted though...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
[MENTION=4344589]matt99017d[/MENTION] (and [MENTION=1007992]everyone[/MENTION])

the more that I think about it => I don't think that I want to support non-rooted Pixels... My kernel is somewhat hardened / restrictive ~ there are a number of things that won't work without root, as well. examples; Managing kernel settings, WireGuard, file-system access to things like /proc + sysctls, etc... some boot-related stuff. *So root is needed...

it's extra work to try and redo things for non-root users and features would still be limited / cut off.... Most people are using root with my kernel anyway and I don't want to be spending additional time trying to support a setup/use-case that I would never use....
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
[MENTION=1007992]everyone[/MENTION]

I've added notes on needing root and a link to the Magisk Beta thread / download links.... SuperSU could be used - but since I don't use it and it tend to have more issues/breakage than Magisk - I'm recommending Magisk + It's opensource, so it automatically wins ;)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] almightysiman:
any way to disable force encryption?I want my storage performance to be maximized.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
No idea - goes beyond the scope of this thread topic / discussion.... Personally, I would never do that. I think having full disk encryption is an important feature.... You will have to google around.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] almightysiman:
Got it!Thanks!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] グリッチ:
I know it hasn't been 24 hours yet, I will update this post later. But so far, wow, so good. Not a single problem encountered, and constantly buttery smooth, probably more-so than I've experienced thus far. I used to have a little chop in a game I play, and now nothing. Very nice work, I would totally donate but right now I have no money lol sorry :p

Did you compress the builds differently or remove something? I see it's around 15mb as opposed to the previous 20+mb, or is it just a slimmed down kernel overall in 8.1?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
i've redone the zip, so that is why the zip is smaller - i had some stuff in there I didn't need. nothing to do with compression.

You can also improve game play (and FPS in general), by setting up performance mode to use the Performance CPU governor in EXKM and switching it on during games (this will cause battery drain though, as it sets the cpu frequencies to the highest values).... Just remember to turn it off after - also don't report battery life if using this, obviously. lol

you can also set;

# setprop sys.use_fifo_ui 1

as root/su from the commandline.... This cause the UI / Render threads to use RT scheduling for the top-app. (SCHED_FIFO vs SCHED_OTHER). This will pretty much eliminate jitter and runnable times for these threads will operate in microseconds instead of milliseconds... However, this is just something I'm testing right now, so mileage may vary.... something you can try though, if you like. (it won't be persistent on reboot).

NOTE: the above sys.use_fifo_ui setting is very much something that shouldn't/can't be used on stock kernels - they lack the supporting code - my kernel has it though... so yeah, not something really supported / experimental - I might enable it though, assuming it pans out after some continued tests.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Understood. To be honest, I wish more people would donate ( a few have, so thanks to them! :) )....

I do think end-sers under-estimate the amount of time and effort that kernel devs put into their kernels ~ It's also something hard to monetize; I mean, I could create an App like EXKM but specific to my kernel; which *would* be one route to monetization / recouping some of the endless hours that I've spent on development, reading documentation, testing , etc... -> but EKXM is pretty good and seems like I would just be duplicating efforts like EXKM aor Kernel Aduitor (both of which I have paid for to try and help support their continued development)....

The kernel is such a critical part of Android / our devices and something that at times can be tricky / frustrating to work on.... I do hope more people recognize this fact and do decide to contribute - it would actually make a big difference;

Anyhoo, enough about that ~ if people are using my kernel and value my efforts; they can donate whatever they like, if they can afford to kick a buck or three my way; that would be amazing and great motivation for continued development.... If they can't afford to, I completely understand / all good.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Hey,

I just wanted to say thanks to a few people who i suppose must have read my reply above to [MENTION=5930088]グリッチ[/MENTION] ....and decided it made good sense to donate / contribute

I REALLY do appreciate it. It definitely helps and makes me feel good about working on this project :) .... It's great to know that a few people understand that it actually is a lot of work... It also will serve as a good reminder for me, when at those times when things are super frustrating; to work on and push through...

So thanks a bunch!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Sooo...

I think the changes I've been working on (performance / battery stuff) is working out. Probably be in the next build. No ETA yet; but soon
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Droid1019:
I'm on 8.1, no TWRP installed, Magisk 14.5. Can I flash this in FlashFire? Or do I need to stick to OP directions?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
AFAIK, yeah. you should be able to do that. IIRC, someone else had reported last month using that method...

I just haven't personally used that method to flash.

if it doesn't work, u can always use the Op method.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] bladels:
I have better battery life with this kernel than Google stock kernel (~5h30-6h SOT vs ~4h30-5h SOT) but performance suffers a little - most noticeable when scroll through a feed with multiple auto play videos.

I like my phone to be buttery smooth so I had switched back to Google kernel.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
thanks for the feedback. glad to hear battery was better than stock, something that will improve more soon.... on the scrolling bit; had u asked, I could have suggested a couple of tips on that.. and my next release shouldn't have that issue... as that's one of things I'm working on / testing right now.

to be clear though, that's not really a reduction in performance or performance suffering, that has to do prioritization, more than anything. (of the ui)...

applications that are actually demanding. games, multimedia, VR, etc; I've already had reports of them running better && the ones that I use, mostly proaudio apps: run like crap on the stock kernel...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] bladels:
I think it's CPU governor. CPU waits for me to scroll to kick in so the ui stutters for half a second then it's buttery smooth. Performance governor guarantees smoothness but I don't want the CPU at highest clock speed all the time.

It's really minor but I've been spoiled by Pixel's sleekness.

I'll give this kernel a try later because I really like better battery. Thank you for your work :good:
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
CPU governor is part of it, sure. I've actaully been reading about Schedutil on lkml and there are a couple of settings that i'm testing, as it's been suggested the defualt values may be less than ideal on mobile.....

but there are other factors though too. power hints, ui/render thread priority, IO scheduler, etc... 8.1 has switched things up, so it'll probably take me a bit to get things well optimized for 8.1 - I was getting better battery under 8.0, for sure... but I've got some changes coming, next build...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Just to add to this;

yeah, performance governor isn't a good option for general use / being set all of the time - it is however a way to achieve peak performance (since no frequency scaling is used ~ which does harm performance for certain pipelines that are sensitive to it; namely, GFX and audio pipelines). I do use it for proaudio apps and/or where peak performance is prefered - just not right now; while I'm trying to evaluate battery life and improve it.

There was actually a wonderful and insightful presentation at Google I/O 2017 by the founder / lead Dev from ROLI on designing proaudio applications and using "enhanced performance mode" - a feature in Android. In his presentation, he had a wonderful graph and explanation on why cpu frequnecy scaling + touch inputs can have bad effects / be harmful to audio.... however, this is semi-applicable to what you are describing, with the initial lag on scroll (and then it smoothing out....

Like I said I'm working on some changes that should improve this.... Changes that I'm looking at implementing;

#1 changing how quickly Schedutil scales up. by reducing it's time / window ~ this should help...

#2 enabling cpu-boost input boostiing (but not dynamic Stune boost). This would have the effect of scaling up the cpu frequencies quicker (while not spiking them like the performance governor does.... after a set amount of time; in milliseconds (maybe 80-100ms), the cpu frequency falls back down.... I actually did this for a while on 8.0 ~ So I'm actually testing this right now.

#3 enabling the UI / Render threads to use SCHED_FIFO/OTHER (rt scheduling for the top-app). which can currently be enabled manually from commandline as root;

setprop sys.use_fifo_ui 1

The only issue with #3 it has the potential to interrupt audio (if it happens to NOT be using the low latency path. my audio driver does improve scheduling for audio; even for audio not using the low latency path ~ but this could still be an issue, so it's something that I'm still evaluating...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
UPDATE: Available from the OP download

#1 -> Mac Address Randomization on Boot is fixed. You Mac address is now static (your real Mac Address)... I had overlooked the cnss wifi driver setting this by default to randomization, so I changed it, for those of you who may be subject to your workplace or home network that use/require Mac Filtering ~ I've fixed this specifically for you! ;)

* You will have to come up with a method / way of enabling/disabling Mac Randomization, if you would like to use it on other networks / in public. Read through the thread; as I have mentioned the rough info how to do this...

#2 cpu-boost / input boosting is enabled. I've kept the cpu frequencies a bit below peak and the boost will only last 100ms, so this might help with the cpu frequencies scaling up a bit quicker - while not having a huge impact on Battery life.

#3 Dynamic Stune boost has been disabled in the build.

#4 I've (re-)introduced a kernel scheduling feature that has to do with load balancing (across cores) of RT threads/tasks... I'm not sure why this code was ever removed (something I've inherited with the initial EAS commits), but after some research, I've not only merged the code back in; but also backported the newer simplified code for this from upstream/mainline linux....

#5 I've changed from using CONFIG_HZ_300 to CONFIG_HZ_1000 in my kernel.... This is a bit of an experiment, but not the kind where things might "go bang!" LOL.... From reading documentation (from AOSP/Google), this might actually be beneficial on the Pixel ~ as it could reduce RCU overhead - which could result in improved performance and potentially battery savings, as well.... at worst, we waste too many cpu cycles and I revert it in the next build. no biggie.

even if #5 is a bit of an experiment - I thought that I would like to get it into more people's hands; as it is hard for me to test battery currently (to some degree) because I flash too many test builds.....

I'm still testing / researching Schedutil and adjusting some default settings, I've seen some examples ->> but people are setting them wildly different.... So I think I may actually contact the author and ask him a question or two, directly - sometimes that really is the best thing to do....

NOTE: I have not enabled the feature in this build that would enable using RT scheduling for the UI / Render Threads - if that is something that you are interested in; please read back through the thread - as I've given instructions on how to test that out.... It maybe be something where, I don't enable it in the builds; but adding a script to EXKM or Magisk to apply on boot is trivial to do.... I haven't decided on that yet....

I found out in the XL thread that KCAL might need some adjustments - so if you've observed that Night Light mode looks very red - that's probably the issue - for now; just reduce the intensity of Night Light ~ I wil look at this tomorrow.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Nil253259:
Just a query.. is the version in the screenshot the latest one? Also, I hope the 2nd shot from EXKM is default settings too.

A but confused as the kernel version is dated as 7th Dec and in the EXKM, input boost is disabled, dynamic stune boost has a value of 15
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
my bad - I think I forgot to update the link in this thread (just did)...

should be 98adabe NOT a4a8f03 build ...

https://github.com/nine7nine/Apps/raw/master/Sailfish_EXNS_eas_98adabe.zip

Thanks for catching that... not enough sleep for me, i think. lol... bed time now. Sorry about that.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
alright. so my average SOT is starting to climb n be similar to 8.0 on the latest release;

i'm still working on improving battery life though.

also, this kernel chews thru more CPU cycles than 8.0, so this isn't half bad, all things considered.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] BBgun1021:
How can I update the kernel from a4a8f03 to 98adabe？ What are the steps？Thanks for your work
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Nil253259:
You just boot into TWRP, flash the kernel zip, and then flash root (I personally prefer Magisk) without rebooting. You're done then. Just reboot your device
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Ok. So a few things that I've been looking at / into;

Wake Gestures:

So some of you may have noticed that Wake gestures are behaving oddly on my 8.1 kernel. My thoughts on the subject;

1. It makes zero sense to me why DT2W is included on the Pixel - It breaks Oreo's Implementation of double tap to wake.

2. DT2W does seem to have an incompatibility with my kernel, it works fine on EX kernel, but again Android's double Tap 2 wake works fine with my kernel ~ So I haven't figured out what the issue here is - but it's annoying ~ especially since the Wake gestures patch breaks something already included in Android Oreo. (and is completely redundant).

3. S2W and S2S work fine, as long as you are using "sweep left" - anything else seems inconsistent or not working. I was getting inconsistent behaviour testing this on EX kernel too... hmmm....

I'm just going to point out to you guys - that I actually hate this feature / patchset and don't even really want to be including nor supporting it. I've only done so, because 1 person had made a valid reason to; semi-broken/warn out power button... But I've now spent a great deal of time messing around with this and it's become something that just isn't worth the effort....

It could be that it doesn't like the cpu-boost driver / input boosting, it could also be that the newly set CONFIG_HZ_1000=y is causing something funny here with Wake gestures.... However; i will NOT be reverting either of these ~ they are far more beneficial than supporting Wake Gestures. It's a ~ improve battery life / performance VS. Supporting a feature that ddoesn't even work properly. = You do the math. lol

So at this point, I'm not sure How I plan to handle this ~ but it may not be immediately fixed.

KCal Advanced Colour Control.

It does seem to have some oddness on 8.1 ... At least for me; after using the Night Light - The colour isn't restored correctly and look saturated and yellowish.... I may temporarily disable this feature While I figure it out. ~ I think it's important not to break android's Default features (and night light should work correctly without the need to reset Kcal's settings after using it)....

anyway, I wouldn't mind some feedback on the above. I probably will disable KCal, at lease until I know it's fixed... But Wake Gestures I'm not sure how I would like to deal with - reverting support; D2TW works fine, as it should provided by Android.... NOT reverting it DT2W doesn't work correctly, and SWS and S2W 'kind of' work...

I'd prefer to just remove support, but that's me... Let me know what you think...?