yashsingh1/xdaforums huggingface dataset:
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Well, My experiment is actually going quite well. Some fixes that I applied seemed to have cleaned up the locking / RCU mess that I encountered last night. I'm into my 3rd round of benchmarks and nothing has blown up (?)... I'm also getting slightly better (and consistent) results too... But I probably need to cheryy-pick a few more patches and test for a long time. = very experimental / totally unsupported by linux or ARM...

Yeah, Linux/android-4.4 is very good.... All android kernels are more linux-like than being actual linux though; they are franken-kernels, with code from everywhere, millions of extra lines of code, crazy backports, etc, etc....

my kernel is obviously the same. But you will be happy to know, that I have ported back a lot of code from the linux-4.4/android kernels (and above). Some of that directly affects core infrastructure, improves performance, locking, etc,etc... It's just tricky (and often painful), gotta be really careful.... Also, with some of the pax/grsec stuff added in, we do actually have some security related code that normally isn't available to linux-3.18 which is nice.... There was just a few patches I had to OMIT due to performance overhead.

I think I also made the right decision to not support installing TWRP. by not reducing kernel size, we get 0.12 sec shaved off boot time and slightly better performance (and I get much better info from the compiler when compiling)...

Just trying to make sure the kernel is good and slightly future proof :)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] siheals:
I can't wait now, i completely agree with your stand I am so used to using fire and the twtp image is really no inconvenience. Perhaps you can get Greg to use your backports in future releases:)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Yup. TWRP fastboot image isn't inconvenient for me either. No reason to have twrp installed, really.

Greg? As in Greg KH? ... Lol. The Chances of that are about ZERO.

1. Linux-3.18 is rather dead. EOL

2. even though the LTS kinda is still going, you don't introduce new features in to LTS. That's not the way it works at all.... it's all bug fixes, fixes for CVEs and the like.

3. The chances of me getting LSE instructions to play nice on linux-3.18 are slim. The basics are there, but there are still problems that I'm noticing, which aren't easily fixable. Requires a lot of fixes, a bunch of backports - some won't apply very easily....

This is mostly just a personal interest of mine and it has yielded fruit in terms of four commits to my stable branch that were relevant outside of playing with LSE.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] blaze9090:
I'm on 8.1 beta and get bootlooping after flashing.

First time I even got magisk to work.

Fresh installation of 8.1, set it up, fastboot boot twrp, install your kernel -> boitloop.

Am I missing something?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Well, yeah - I can't really support Oreo 8.1 -> there is no kernel source code and it's an early developer preview.

In fact, I specifically mention this on the OP.. this kernel is for Android Oreo 8.0 (a stable non-dev release)... I think you will find you are going to have lots of problems with non-stock kernels, if you plan to already be dogfooding google's beta releases...

I know of 2 other people that have had my kernel working on 8.1, but WiFI wasn't working. So it's kind of pointless.

You should probably just stick with a stock kernel, if you want to run the developer preview. Sorry.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
So I'm making some progress in preparation for the Nov firmware update.

I've merged in (and am testing) a number of fixes from Code Aurora and a few other places, where people have been running KASAN against linux-android-3.18 sources... So far;

- a bunch of fixes for use-after-free bugs

- a bunch of fixes for racy code (race conditions).

- Fixes in locking, RCU code in a couple of spots

- memory leak fixes in a few places

* I suspect I hit some of the racy code in my experimental LSE branch (in fact, I know i did).
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
For anyone interested, I've been keeping at it.

Merged in 23 commits today;

=> half are bug fixes - some from upstream, some from code aurora. (mentioned above)

=> added lockless wakeups for futexes from linux-4.2

=> added helpers around the i_mmap_mutex from linux-4.2 (certain lock mutexes become r/w semaphores)

=> locking / rtmutex fixes that I bumped into from using my LSE branch

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

I figure I would post this, even if i'm not ready to update the OP download link, as I'm still testing... But I'm happy with the progress. Some of the bug fixes / locking fixes are great - hard to bump into without using my experimental branch, but nonetheless; legit bug fixes and improvements... ;)

edit: I'm definitely happy with this build. the changes are proving to be good...

I also forgot to mention that I also tweaked my init rc a bit... now on boot it biases performance via sched_cfs_boost, then resets it to zero after boot completion...

tbh, I think we get fantastic boot time to begin with (by not reducing the kernel size, shaves 0.12 sec), but boosting probably shaves a fraction more off.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] siheals:
Nice, I can't believe you could get some 4.2 patches to work. The boot speed increase is noticeable as well as the battery usage. I hope you keep up all this as there seems to be little happening for this phone.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] blaze9090:
Is anyone getting this kernel to work with latest pixel dust oreo?

Though it's 8.0 it seems to have trouble with custom kernels.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] matt99017d:
[MENTION=7810360]nine7nine[/MENTION] when can we expect alpha or beta update?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
ya. it is a lot of work... also, challenging because many of the coming changes are kind of specific, re-engineering etc.. so kind of on my own, in a sense...

so I won't push anything until i'm fairly confident that all of the changes are settled and that things are working very well. for the most part, they are.... and I think I've solved all of the little splats..

However, I still am working on and need to resolve PM / irq handling parts. once, that's all switched over to pm_wakeirq, I'll probably push a test build. (not adding anymore features for now.)

when i feel that it's ready... my current local builds are massively different than the stable build. there are still a couple of issues to resolve before I'll be ready to push a build... no asking for ETAs, the stable build is fine to use and I'll get a build to test when I can...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] matt99017d:
Fine fine. I know it's Tabu I just couldn't resist. Keep up the awesome work, totally looking forward to what you have coming down the pipeline!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
haha. it IS taboo to ask ?

i'm definitely getting close to pushing a new test build, but there is just that 'last 5%' left to do; which tends to be the hardest... so I could get it resolved over theweekend, orit might not he sorted for a week (I have no idea)...

I had thought of selectively migrating certain features from my local build to stable; but that just adds up to a lot more testing and work... so i'm not going to do it that way...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
[MENTION=7810360]nine7nine[/MENTION] when you do push a test build, will it include a test fix for the audio?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
*** GOOGLE PIXEL / XL ONLY ***

Not sure about telegram, or if I want the additional work.... I may end up posting a test build that has some rough edges, since since people seem to be wanting to try a new build.... may be If i can get this PM chunk sorted, I'll just post one, laying out a known issue or two - so there are no surprises...

yes. it's one thing or another - and I have patches for both. So for sure, there will be a fix to test.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] matt99017d:
SWEET! looking forward to the test build!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] siheals:
Telegram is usually a bad idea as it just for up with morons very quickly. Putting a test build could be a good idea but there is the danger of people using it who don't really know what they are doing and posting things that aren't kernel related just ROM issues.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Love4Taylor:
Have plans to support z3fold?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Hmmm, since the last time you asked? ;) It's ongoing, but;

- updated/reworked some scheduler code

- converted a few drivers away from using legacy suspend

- still debugging some PM related code (fixed an issue with not being able to enable some PM debug too).

- changed/simplified how the cpu_pm_notifier works (reduced latency and locking, as well).

- integrated a couple of features from PREEMPT_RT (using some now, use some later).

- working on some patches for MM subsystem. (I've got a bit more to go; but soon it'll be much easier to share code between my 4.4 kernel and this one).

- improved the threaded irq handling, specifically pertaining to shared irqs when combined with certain irq flags - that didn't work as expected/required (This is good, because I was trying to use some backported driver code that didn't behave correctly due to an issue relating to this - so now I can test it again).

- a few fixups to MM, RCU, drivers and other bits.

- binder updates and tweaks (ongoing, I want to remove/rework some of the locking in binder).

Nothing overly exciting, just minor stuff; on top of the more major changes that I've already made in the last while.....

NOTE: March 5th update will likely be the stable build + March 5th patches + LTS + a number of fixes / cherry-picks....

*** IF my local build is as stabilized as it seems to be (my last 2 builds have been really good... so just giving it a good run to see if there are any big issues), then I will probably put up a test build too ~ I'm just trying to nail down a few last bits, before doing that.

compressed page allocators are interesting and I have played around with all of them. For now, I won't be adding z3fold (nor will I be enabling every allocator under the sun, ever), but after I wrap up changes that I'm making to MM - I'll probably revisit allocators... it's not the highest priority, wrapping up all of my bigger core changes is...

any reason that you are after z3fold specifically?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] matt99017d:
Can't wait!!! Thank you for your hard work!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Hey guys,

I ran out of time last night. I was home later than expected, then hit some merge conflicts with the KPTI patchset that google has included for Marlin this month.... I'll have a look at this when I get home after work and get a stable build up...

until then, the feb kernel should work fine on March update. (my dev kernel is - so no reason why the stable wouldn't).
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
UPDATED:

I've merged in the March / KPTI kernel patches, but I haven't added LTS && I haven't cherry-picked through my dev branch yet (for bug fixes and a few less invasive changes).... This build isn't very different from last month, but I still ran it through a cycle of benchmarks and stability tests, just as I wasn't sure ats to what the impact of KPTI would be. Seems to be unnoticeable. good.

~ there's actually more than I thought to go through from my dev branch (just for fixes and one-offs, maybe some non-invasive changes too... - So i'll probably update the stable build again in a day or three - with all of the (stable) changes from the dev branch and also I'll add in LTS.

I'll also try and get up a test/dev build too. (at the same time).
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
[MENTION=7810360]nine7nine[/MENTION] we all really appreciate your work. Love this kernel. The battery and performance with this kernel is noticably better than stock too.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Thanks! I'm glad it's working well for you!

yeah, hopefully I can get wrapped up with my v3.x branch (dev branch) and get all of that goodness into the wild, sooner than later.... down to the last hard / annoying bits to fix, but starting to be in really good shape.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] matt99017d:
Any chances that your next update will include support for Android p?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
the current stable build can run with android P now... people are already using it on P... but I've also looked over the dp1 kernel changes...

-1/2 of the P kernel patches have been in my kernel for months. VDSO, timer stuff, a few musc fixes, driver bits - stuff from AOSP. (which I have been pulling from for a longtime).

- They've also updated binder to a newer version of the fine-grained locking binder (which is much closer to what exns-eas already has.)

- they also added some instrumentation to cpufreq/scheduler, etc. - not critical, being as it's for testing purposes, not for end users... (I have this in my Dev branch).

- they backported the 'thread_info in task' stuff from newer kernels. (is in my Dev branch).

the stable build should work fine for now, even missing a few non-critical patches on Android P....

that said, I'll probably push a Dev build out tomorrow, it'll gave some potentially rough edges, but it'll work on both O and P.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] matt99017d:
[MENTION=7810360]nine7nine[/MENTION] that is the best news I've heard all damn week. Looking forward to it!

---------- Post added at 01:45 AM ---------- Previous post was at 01:45 AM ----------

[MENTION=7810360]nine7nine[/MENTION] that is the best news I've heard all damn week. Looking forward to it!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
The current build [ 51eafO1 ] is the stable kernel - v2.6. It is patched for March, but does NOT contain the more massive rework / updates... It does however, contain many of the patches from the DP1 kernel (because I already had them) from AOSP, mainline, etc... The stuff that isn't applied, isn't anything that would be specifically required by android userspace (AFAICT), so the stable build should be fine on P.

the v3.x branch (dev/unstable branch) is what I use and where most of the development is ongoing... It's a big rework, some updates and some non-standard stuff that I'm working on....

however, the v3.x branch still a has few kinks. So yeah, still bug fixing; but it's down to just a few issues ~ I actually fixed a critical bug yesterday (probably the most critical and annoying. lol) and I had hoped to push a dev build up today, but; I may have introduced another. lol - I think I found the issue and am (just now) testing that I've resolved it...

So maybe tomorrow night, if things go well over the next 24hours; I'll put a v3.x build up, with a few caveats/warnings ;) ...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
enough to have double the emphasis! ;)

Well, you'll have to wait another day (for a dev build), I'm afraid. (read my last/above post).
[Google Pixel ROMs, Kernels, Recoveries, & Other De] matt99017d:
Thanks! That darn internet not going fast enough and I press submit twice...

Thanks for the update!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] KittyRgnarok:
Hey Nine been using your kernel here and there when I remember to flash it and was just wondering where you host your test/Dev builds? Separate branch on your GitHub? Been meaning to stay updated on this kernel and help you test stuff but have been in flashing hell for a while lmao
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
I think he said it was the 3.x branch. Just saying if you build it I wouldn't post it just out of respect
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Alright, So I am posting an v3.x build, for those interested;

https://github.com/nine7nine/Apps/raw/master/exNoShadez_eas_v3.x_unstable.zip

IMPORTANT / PLEASE READ

:

=> I largely suggest staying on the stable build, it works well. The v3.x kernel isn't (yet) a replacement for the stable build. However, I think going forward I'll post snapshots every few days, but they will be marked "unstable" for good reason. So consider all of the below, before flashing;

#1. I'm still working on / ironing out various changes; this means that there are / may be regressions, quirks and bugs.

#2. There is a known critical bug (but hard for me to trigger) that will cause a kernel panic / crash your device (I've triggered it twice over about a month or so). I forgot to save the traces (the one and only time I had a good trace. Grrr?!#%!) and thus haven't had a chance to attempt to fix the issue yet...

#3. There is potential to bootlooping... Specifically; after flashing the kernel, it may bootloop (just restart your phone again, it'll boot)... Additionally, If you happen to crash your device; it will probably bootloop on next restart / power on. This is flaky right now -> I'm aware of the problematic code, but it's going to be a bit tricky to fix (and time-consuming); I need to sit down and play a game of "git blame" on mainline and android-4.4 kernels and make some local comparisons/adjustments/decisions to fix this up properly...

#4. Don't report crashes without logs to go with it (it really isn't helpful). /sys/fs/pstore, kmsg and/or full bug reports are helpful. (for full bug reports you can PM me, rather than posting publicly)... and/or if you've found a way that I can reproduce your crash - that is even better.

#5. Don't focus on OR report your SOT / batteryStats to me, or in the thread.... Why???

- you wouldn't be showing me anything that I'm not aware of - I run the kernel on my device, right? ;)

- these builds are NOT biased towards battery saving or well-tuned. (there are reasons for that).

- I'm still working on ironing out some PM-related code (yes, PM = Power Management), RCU and scheduler code (all of which can/will/do have an effect on battery life).

- I'm currently testing/using some settings that may actually impact performance and SOT negatively.

- I won't focus on fixing or improving SOT or anything like that, until after I've resolved other more critical issues that are higher priority (see: #1, #2, #3)....

Last, but not least;

If your big concern is SOT, stability / mission critical use and/or if you are inexperienced with debugging, dealing with "alpha grade software", etc => then please just use the stable build.... At some point, when I feel the v3.x branch is ready; I will promote it from "unstable" to "beta", which will be a better point to have a wider audience of users...

I'll write up another post about changes, as there are lots. But i'll do that later though, no time just now.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] almightysiman:
Testing now,so far so good,and already see some speed improvement,Thanks!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
OK, so more details about the v3.x build (that I posted today);

Changes;

=> various subsystems updates and rework; FS, File locking, VM, vfs, Block, tracing, etc.

=> Introduce simple work and wait queues -> implemented in bock, rcu, sched/completion, elsewhere.

=> introduce and implement rcu_sync infrastructure && rework && tweaks to RCU and rcu_sync

=> Scheduler, locking and futex rework and updates. (several iterations)

=> lockdep pinning rework / update && load balancing rework.

=> Introduction of locallocks (essentially annotated locks. implemented and used in various places)

=> EAS updates from android-4.9-eas-dev (My kernel is caught up to this branch)

=> MM subsystem updates (several *painful* iterations. lol), locking changes && introduction of the oom_reaper

=> Binder, Ion, msm_ion, etc -> updates and reworks

=> driver updates and reworks (synaptics_dsx, i2c, msm-i2c, etc.... work in progress)

=> Workqueues: updated to 4.4 + backports. decoupled worker accounting from scheduler, locking/rcu rework.

=> genirq, forced threaded irq handling changes/improvements.

=> tty updates and fixing all related drivers.

=> introduce pm_wakeirq && implement it in various drivers (work in progress)

=> PM updates and rework (work in progress)

=> Introduce soft && hard lockup detector watchdogs

=> Introduce Hardware Latency detector

=> fixing references to HZ in various places.

=> lots of bug fixes; compiler fixes, upstream/backports, driver fixes, backports from newer msm kernels.

=> debugging and instrumentation added in a few spots, that will be removed later.

I've probably forgotten a few things. any questions, ask... Also, re-posting the original post, with status/warnings && download link to v3.x build below;
[Google Pixel ROMs, Kernels, Recoveries, & Other De] siheals:
Working well so far.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] almightysiman:
So much work and all done it by yourself!wow!good job in deed!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
thanks guys! It should be working well.... Even the kernel panic that happened was just twice over about a 6 week period and TBH; I'm not even positive that the 1st one was the same bug (it just seemed to be)... There is also the possibility that the panic doesn't happen any more (they happened weeks ago, so idk - until/if/when it happens again ;)) .... So really, once that is ironed out / gone && i fix up the bootloop issue; things are in a pretty good state (assuming no more issues like that).

yeah, when I said it isn't well-tuned; that doesn't mean it it's slower than the stable kernel (it's not), it just means that there are still adjustments and tuning that needs to happen. for some stuff, the v3.x build is faster / more responsive, for sure.... but at the same time, there are also places where it may be slower or audio may encounter a buffer underrun, etc - due to debugging being enabled and/or other factors. (to be fixed/addressed later).

keep me posted on how things are working and/or if you bump into any issues.

lol. No, not exactly all by myself - I'm standing on the shoulders of giants; lots of great stuff merged written by many talented developers, over many years...

i'm left with the research, the task of deciding what/how to integrate, some porting efforts and other fun stuff... That isn't to say that I haven't had a ton of work, effort and time put in (because obviously I have), but I'm just one of many....

the hardest stuff to work on (for me) has been the scheduler code, MM subsystem (the worst. lol) and some of the locking stuff ~ which all seems to be in reasonably good shape; all things considered.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Yeah, I need more info. this is all very vague. Not only that, but;

* in your case, you may actually want to connect your device to your PC and run 'adb shell' A.S.A.P on boot. adb typically works around or just after the boot animation starts (g logo) - then you would quickly start 'logcat' and watch the output (something may pop out at you, but you can save it too and I can have a look).

...and no, that wouldn't be a known issue or normal, at all. I don't know of anyone who has had a similar issue to yours (and I know lots of people running v3.x on Oreo and P)... *** I'm wondering if there is something else at fault, on your end;

- do you have any mods (magisk modules, xposed modules, etc) running?

- anything else on your device that may be modified or odd ball, that you can think of...?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
[MENTION=7810360]nine7nine[/MENTION] I have been pretty busy so I haven't had time to flash yet. Does this include the potential sound fix? I would test but haven't had time