yashsingh1/xdaforums huggingface dataset:
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
#1 - your system is not up to date

#2 - I can't and won't support outdated systems

#3 - I've deleted those binaries and I no longer support 8.0

The title of my thread clearly says "kernel/Oreo-8.1.0" .... and there is only an 8.1.0 download. I would prefer that you didn't try and track down an 8.0 zip and kept your Device up to date, instead.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] rbaskin2009:
Fair enough; I'm just following that guide, and I wasn't sure if the install method would work with the newest kernel. The link in that guide is for Oreo 8.0, but it links to this thread titled Oreo-8.1.0 (which I misinterpreted as Oreo to 8.1.0), so I thought that that meant everything from 8.0.0 - 8.1.0.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
[MENTION=4810220]Homeboy76[/MENTION]

Could you please update your link to my thread (in your guides), as to not cause confusion ~ I don't support 8.0 anymore, as it's out of date && I've moved onto 8.1 support... I had someone from here / using your guide comment and wanting to track down an 8.0 zip...

I won't support that / out of date versions of android on their phone and I strongly tend to discourage people from not staying up-to-date with Android updates/upgrades...

Thanks!
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
all good. [MENTION=4810220]Homeboy76[/MENTION] will see my comment and hopefully fix that...

You should really consider moving on from using 8.0 though. it's done and won't see anymore updates on the Pixel.

EDIT: NO, do not flash the 8.1.0 kernel with 8.0. You'll get a bootloop, I would imagine.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] rbaskin2009:
Yup, upgrading to 8.1.0 now as per your better judgement using the factory image and adb. Thanks for your insanely fast response. I'm pretty savvy when it comes to this stuff, but I've been out of the game for quite a while (intentionally) so I'm just getting my sea legs.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
No probz. Insanely fast response is just part of trying to keep on top of things.

But yeah, always good to make sure one is keeping up with updates. + generally speaking, 8.1.0 is better than 8.0 and better suited for my kernel....
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] Homeboy76:
Gladly, thanks for the information.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
Awesome, thanks!

btw, I saw a link to our thread on Reddit. ;)
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
NEW TEST BUILD: https://github.com/nine7nine/Apps/raw/master/TEST-v2.1_460df33.zip

Changes;

- dt2w should work ok now.

- atomic_inc family supported in core code && arm64

- a few bug fixes to optimistic spin queue code

- restoration of a patch that should've never been reverted during EAS integration.

- increase of RT priority for mdss and kgsl

- minor change to futex code

a couple of these patches *should've* been in the stable build, but are not (as I didn't uncover them until now). I'm still digging through previously reverted commits, so each new (or three) build may contain fixups like this... Some of these reverts could be leading to subtle issues and corner cases where something goes sour, unpredictably so (in previous builds for 8.1) - but only one case of that that I know of. very random too... (in the Pixel forum)

So, if you want to test this, please do .... if you have encountered any issue on the Stable or previous test build - please use this and see if the problem persists....

make sure to report back. thanks!
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] -iNSiGhT-:
Does the kernel dt2w work differently from the stock one (I use the stock one, at least, I checked this option in gestures)

Do we have to re-flash Magisk after each kernel flash?

Thanks.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
Yes, it does work differently, arguably better. As you avoid going through the extra peaking screen and straight to the lock screen - disable the stock; Double tap 2 check though, if using DT2W...

yes, you must re-install magisk every time you flash a kernel - all rooting works that way. you can download magisk.zip from within Magisk manager to keep a copy locally on your device (via install -> Download Zip Only").
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] -iNSiGhT-:
Thanks,

Will try the kernel dt2w. I suppose it's enabled by default?

I can't flash from my device since it's encrypted and TWRP can't read internal storage.

I use a flash drive with the Pixel adapter.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
No, it's not enabled by default. You must turn it on. I only set certain more critical kernel settings to be enabled or persistent by default. I generally don't force end users to use specific features that they should be able to enable or disable at will.

TWRP can read your storage, if you disable your passcode / lockscreen. Then it shouldn't have a problem - this is a new issue on 8.1 with the latest TWRP. Hopefully, it is fixed soon.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
So pending a detail or two, I likely will be phasing out my other builds in favor of the Binder_rt build.

- I've had quite a lot of feedback via the Pixel forum, PMs and email (and a couple of friends using it too).

- The Binder_rt build seems to be very stable for everyone.... not too mention just all around better.

- there seem to be no drawbacks and quite a few benefits to that build over the others.

The one thing I'm waiting on is; I've joined the Android Kernel Developers Google Group and am currently waiting to see if I can't get some help with porting a missing Kernel function into Marlin's sources ~ this particular kernel function is what's stopping me from having Binder be sync'd with the AOSP binder implementation.... I'm hoping to resolve this sooner than later, at which point I will be able to merge in those commits (and test them).

In the meantime I'm working on a few backports to the audio driver and a few other bits (taken from Wahoo/Pixel 2 kernel sources). I've also pulled in a few fixes to binder from Wahoo, as well....

So I might post a test build for Binder_rt tomorrow - as it's accumulated a number of changes, bug fixes, etc.... I'm not sure If I will have any resolution to the missing kernel function - but that doesn't affect pushing a test build....
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] Donric13:
well, if at some point you are bored and want to test my kernel on 8.1, go for it. ya never know: maybe it will work. the reason I say that?

lol[/QUOTE]

So i was bored (..) and flashed binder version on dp1. Phone hanged while booting in "G" logo and then reboots. Think could be because dp1 is still on october security patch while your kernel is based on november security patch. But doesn't matter. Gonna wait until official 8.1 sources drop and your kernel is based on 8.1.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] spr33:
Installed the RT build just and will run with it over the weekend and report back.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
sounds good. happy Friday.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
not that it matters, but due to flashing builds (good and bad ones, frequently), every once in a while my phone reboots on the g logo, before successfully booting. kinda rare though...

ya, could've been the patch level, or something else... I was mostly curious, as like I said; someone did try it with my previous kernel and it did boot. everything worked except WiFi - but that kernel had some issues, in general (that's why I started fresh, now things are stable), so I had thought it might he possible that WiFi worked now...

no matter. I'll test it on 8.1 eventually.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
[MENTION=1007992]everyone[/MENTION]

So Binder_rt is now the only build going forward that I am publishing;

-> It's the best build

-> cuts down testing time for me.

-> speeds up development.

-> Has proven itself to be stable.

Soo... I've updated the OP info && Later on I will be publishing a test/RC build with my latest code/commits + 3.18.84 lts exNoShadez-eas. I'm running this build now - but I like to give things a good run myself, before ever posting... thanks.

NOTE: The OP download hasn't changed - so no need to update same build.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] ChongoDroid:
Running great here. I've got an hour of usage in so far and I'm still at 90%.

I'll report any bugs and battery life after some usage.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
Cool. yup, report back any issues, how your experience has been... all that jazz.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
So i'm just finalizing a few changes to the audio driver - no luck backporting some gapless audio changes that I AM going to backport - still working on it; as the changes are a bit tricky to backport from Wahoo (but are worth the effort).

The changes I am working on; are improving Quality of Service in the audio driver, as well as re-prioritizing some of it's critical threads. The reason:

Currently, Surfaceflinger's threads are FIFO threads with slightly high priority ~ This is improves responsiveness and keeps many of the system's other threads from disrupting Surfaceflinger (which is great!), however - it also causes Surfaceflinger to occasionally disrupt audio playback (causing "clicks and pops" under some circumstances - which I can easily reproduce, with a bit of effort).... * Currently, in my kernel - the audio driver very rarely has buffer underruns and even when we do get "clicks and pops" - the audio driver itself usually hasn't experienced a buffer underrun ~ these are caused by surfaceflinger.

So the idea here is to get these critical threads to have higher priority than surfaceflinger - so that these "clicks and pops" never occur... It's a bit tricky, as I don't want to 'steal" too much cpu-time from surfaceflinger, either. Priority scheduling in linux and android can be pretty tricky.

That said - I _think_ I've ironed out the above - just gotta test it a bit more... That will be my last bit of tweaks before pushing a test build.

any remaining underruns or "clicks and pops" ~ would likely be solved by backporting the gapless audio changes.

the remaining ones after that; caused by cpu frequency scaling and cpu_dma_latency.

just a few interesting bits I'm working on.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] JS.zip:
Exciting stuff, any improvement to audio is much appreciated.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
oh yeah, Audio on android has always been an issue - less so on Nougat and (in particular on) Oreo, but being as I use proaudio type apps; synths, drum machines, loopers, dsp processing, etc ~ it's an area that I really notice when things are less-than-ideal...

imho, a frame drop or two with FPS (graphics) is far less noticeable, than when audio drops out ~ For years, this was a huge problem on the Linux Desktop. Anyone using proaudio devices and applications would need a kernel patchest called PREEMPT_RT to get low latency / a proper proaudio experience. Mainline linux is pretty good now, so while there is still a need for that - less so, then 5-10yeaars ago...

On android, while it is possible to use PREEMPT_RT (there was at least one academic implementation, called RTAndroid with it) - This wouldn't be ideal to be using on our Pixels ~ we don't actually need the real-time requirements that those modifications bring. *It would also require modifying android user-space (as RTAndroid did) ~ something that I'm not interested in doing, at all.... So instead, I'm aiming to improve "soft" realtime. (a bit of a non-sense term), but people often refer to PREEMPT_RT as being "hard" real-time...

So I'm making all of the necessary modifications to Binder, drivers, scheduling, locking, etc in the kernel to where we get a far better experience, can drive down latencies and deadlines where it matters. Even simple benchmarks, also show hints of this. for example, in geekbench; It's easy to compare memory latency to stock (or other pixel kernels);

exNoShadez-eas:

Single-threaded / Memory Latency: 175.8ns

Multi-threaded /Memory Latency: 166.8ns

stock (taken from an Oreo 8.1 benchmark result);

Single-threaded / Memory Latency: 431.0ns

Multi-threaded /Memory Latency: 228.8ns

* these numbers vary a bit on each run, device though (only marginally so on my kernel 20-30ns, while on stock 100ns+ or more. we get more deterministic behaviour). But the takeaway is that this is an easy/obvious example; that shows reduced latencies....

I haven't really pulled in the standard linux tools onto my device for more scientific measurements (although, I'm very familiar with them / have used them quite a lot on my desktop Linux machine).... I may cross compile cyclictest, at some point.

Another takeaway; All of my modifications center around the Pixel. Some are fairly specific to our device and drivers. Binder_rt might be portable to other devices or other Marlin kernels ~ but being as I only test with my rather large and invasive changes to Marlin's kernel sources (touching lots of scheduling, locking code, etc -> on other devices/kernels it could cause explosions / run like garbage. lol.... But hey, what can one expect - I use the Pixel, no other android devices, soo.....
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] ChongoDroid:
En route to a solid day of battery life ?
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
TEST BUILD: https://github.com/nine7nine/Apps/raw/master/Marlin_exNoShadez_eas_3.18.84_Binder_RT_f50b1e1.zip

EDIT: This particular build may have boot problems on Marlin - I will update / post a new build later - just use the official release, for now. thx

So this is the test build that I've previously mentioned. It has a rather large set of changes (but I've been running variations of it on my device for days now). Do NOT feel that you need to run this build or anything - if you are happy on the stable build; but anyone who would LIKE to run this build and help out with testing ~ that would be awesome! .... I test a wide variety of applications against each build - but obviously, I'm just one person - so having other people test helps.

It you bump into any issues / regressions. Let me know - and if they are something that I might be able to reproduce - point me in the right direction, I will have a look for myself....

Changes:

- Linux-3.18.84 lts

- the majority of locking, Scheduling, Workqueues subsystems from Mainline; leading up to linux-4.4. * some changes ommited/not needed, while others I'm not integrating yet ~ in particular with certain scheduler and locking changes.

- several commits to binder (a bug fix or two + some debugging related code)

- several commits to the audio driver (although, I am still working on some of this for the next OP download link / release)

- several misc optimizations ( i have some others to commit, as well. But they'll be included in the final build).

NOTE: every once in a while, I do get quirkyness on first boot, after flashing a build. meaning; My pixel boots to G logo, then either;

A). resets after a second or two, then boots normally

B). sits on the G logo screen, but never boots

=> if A). happens. it will boot up fine upon rebooting.

=> If B). happens - just hold down the power button + Vol. down together - it will reboot and boot up.

This seems to only happen every now and again, but if it happens to you - feel free to report it, but know that this does periodically happen, but infrequently.... So just a head's up. No need to panic or be overly concerned.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
Nice. Seems like you get similar usage as I do - between 6-7hrs SOT, maybe more -> depending on usage...

thanks for posting, always good for others to see this kind of thing - so they know what to expect.... I really appreciate it. :)

you probably also have noticed that when the sceen is off / deep sleep - it has about 0% drain too, eh? ....

I don't use any funny one-off tricks that some other kernels do. Examples; using noop + io switcher to reduce consumption (during sleep) or any of franco's "power saving patchwork"... I use lots of upstream code / backported and tend to avoid all of the downstream stuff, as much as possible.... Not knocking any of those tricks, but EASv1.4 does it's job without them and I prefer following upstream linux (and aosp kernels), when and where I can...

NOTE: I'm still working to improve performance AND battery life - it's an ongoing process. trying to get the rest of the upstream code that I'm planning to integrate, first.... So I expect I will be able to get some performance gains + longer SOT.

EDIT:I'll try and post some BatteryStats related stuff too - but I have to wait until things "settle" after flashing a few tests builds (my stats aren't super accurate right now)... I can post from both Accubattery app and BatteryStats in settings app.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] ChongoDroid:
Also drain is lower under load. Tested a handful of games and the drain/heat is definitely lower.

I'll flash the test build after a full battery cycle.

Something to note is that pixel/pixel 2 are now reporting battery life differently (on device model now) so it's good to measure a full cycle of battery for a more fair comparison. So far so good though.

Sleeps like a baby when it's supposed to. Well behaved kernel ?
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
Hey thanks for the feedback / report!

Great to hear that you've noticed some improvements, already.

I use Accubattery to keep track of batteryStats. It's been pretty accurate, when compared to using BatteryStats in system settings.... Also, over a given period; as I watch the average estimates improve - I can tell that I'm making improvements on battery life, when they happen....

It's only when I've flashed a bunch of builds in a row that things get inaccurate - requires a bit of settling time, and yeah - a full charge.

just note on the test build - that it IS a test build. So there could be regressions. Sometimes that happens, sometimes not. Also, sometimes takes me a test build or two to iron that stuff out..... I am aware of one - but I've already fixed it (and I'm not sure anyone else will hit it - requires some fairly non-realistic setup/usage to observe).
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] ChongoDroid:
Yeah bbs and accubattery are good tools for sure. I was just referring to this change http://www.androidpolice.com/2017/1...estimates-accurate-personalized-device-model/

I don't have many apps installed but the ones I do have are more responsive to touch. For instance, the resource heavy ones I use to test are Google Earth (rotating and pinching in and out) and I can tell it drops a lot less frames than previously. I'll enable the screen counter and try to measure it when I get more time.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
I hadn't read that article. I do use both AccuBattery and BatteryStats in settings... Earlier on, in development, I had been tripping over some commits to do with EAS and upstream commits (while working to reduce battery drain to pretty much zero when sleeping) ~ and was getting inaccurate BatteryStats ~ so I started using Accubattery.... Eventually I resolved the inaccurate satats, but discovered that AccuBattery was generally better for my own use / for testing purposes...

Ya, google earth does whip along nicely with my kernel. I like occasionally spinning the view. lol... I try to test with some games too - but I'm not super invested in playing games, the downloads are huge (for the really heavy ones) and the notifications are a bit much. lol.

I also test with YEBIS Demo (egl demo), it's nice because it prints fps and you can add more gems to the render, move around the objects, etc... (it's in concept similar to the old "fishBowl" Microsoft demo for benchmarking browsers)....

If by screen counter you mean gpu profiling ~ one thing you will notice is that when there is no system load, it tends to drop frames more - like if you are navigating through system settings or something - but as soon as it's under load; it doesn't drop frames. I think this is due to EAS / scheduler code. it kind of "clamps" or biases aggressively for power saving.... I determined this by using my youtube player (that has background playback), and then testing the places I was seeing the frame drops - they vanished....

But for all practical reasons; dropping some frames when there is no load, really isn't a bad thing. imho... What matters is that it doesn't drop frames when actually say; using Google Earth or something like that....
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] Nil253259:
Just flashed the latest test..too early to talk about battery... but I'm enjoying the fluidity and overall responsiveness.... Thanks for your time and effort :)
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
cool. ya, I (personally) have a pretty good grasp on battery life with this build and the release build... but for sure, verify things for yourself, share that in the forum too, if u like.

with this test build; I'm mostly concerned with any performance or audio regressions, any bugs, etc... the amount of changes to the kernel are quite substantial;

- many code changes in locking, scheduler code - all critical/core subsystems, the few binder related changes and audio driver.... ***lots of places where things could go wrong. lol. especially with scheduler/locking code. (potentially scary parts of the kernel to touch.).
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] -iNSiGhT-:
And you're right.

Ok, I usually set a pattern lock (in addition of fingerprint) then i moved to digit code as TWRP was asking for a digit code... No luck...

Will disable fingerprint/pattern to flash.

Thanks for your help !

EDIT : think 'll still use my flash drive to flash since i've to re-configure fingerprint from start after disabling lockscreen...though i read it's good to refresh fingerprint from time to time.

Anyway, it works. 2nd test build flashed through TWRP. ;)
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] ayylmaomyman:
installed

will report performance in a few hours
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] almightysiman:
On stable build normal reboot could trigger this problem,and now that I am on test build,the problem seems gone,weird.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
Not necessarily (weird), really. there are big differences between the stable and test build (and the latest test build).

I have a pretty good idea of what caused the problem now (as in I have a stacktrace). It's just less likely to happen on the test builds... It may not be entirely gone though ~ but I have something to go on now; So I'll be looking into fixing the particular code that may be problematic / the root cause.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
[MENTION=7721249]almightysiman[/MENTION]

So that particular issue - I may have just fixed, but it's a bit of a whack the mole game => as something else popped up, after fixing it. lol.... It's all good though; I know how/where this stuff was introduced and how to fix it -> It's sort of my own fault for trusting the initial EAS port to the Pixel, I should've just done it from scratch myself - I wouldn't have reverted a bunch of commits that should've been left alone....

So now, I have to maunally re-apply and manually fix, as I go. (because they don't cleanly apply). It's super annoying, but rather than complaining; I will just fix it ~ Then on my next big rebase: I won't pull in a range of commits/reverts that broke this stuff and ditch all of the commits that I'm working that cludge around the problems.... So for now; less than ideal way to fix - but whenever I rebase - should be nice and clean....