yashsingh1/xdaforums huggingface dataset:
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Ok, sooo..... delays, delyas, delays..... but some progress;

So I haven't been able to push Pie builds due to some (subtle) conflicts that are causing me grief (not merge conflicts, just incompatibilities that introduce problems).... This is compounded by the fact, that while i do have some off-time/away from work ~ i have some other personal stuff going on (nothing bad) that is occupying a lot of that time, so it's slowing me down a lot.... by the end of the week, I am going to get really busy ~ so I basically need to get these issues resolved before then, but finding the time is difficult.... So it may be a couple days before I can get P builds up, but obviously v2.8.2 will work until then....

Now, onto the progress; I believe I've narrowed down the changesets on Pie (from the DPs) that are the cause of the problem. Currently (as in the last 10min), I've got my v3.7 kernel (the 8.1 kernel) working on Pie, just as the v2.8.2 has been (at least, it appears that way - I'll know for sure by tomorrow).... If v3.7 pans out, I am going to do the following;

1. publish the v3.7 build that works on Pie, which was for 8.1, but has a lot of changes since the July build. (that I'm testing now)

2. Then I'll Selectively revert/cherry-pick through all of the android Pie Marlin commits, avoiding the problematic commits...

3. I'll take all of those (non-problematic) commits and (re-)apply them to both kernel trees + LTS patchwork

4. Then build + Publish proper Android Pie v2.9 and v3.7 for you guys

The problematic stuff will get resolved (100%), but I see this as the best compromise and way forward, with limited time / resources.... Then I can work on the tricky bits and commit them back later (in a few weeks), when I have more time to do so...

again, sorry for any inconvenience ~ but it hasn't been too fun for me, either! ROFL. I wanted to smash things yesterday, today a bit better.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Ok, sooo..... delays, delyas, delays..... but some progress;

So I haven't been able to push Pie builds due to some (subtle) conflicts that are causing me grief.... This is compounded by the fact, that while i do have some off-time/away from work ~ i have some other personal stuff going on (nothing bad) that is occupying a lot of that time, so it's slowing me down a lot.... by the end of the week, I am going to get really busy ~ so I basically need to get these issues resolved before then, but finding the time is difficult.... So it may be a couple days before I can get P builds up, but obviously v2.8.2 will work until then....

Now, onto the progress; I believe I've narrowed down the changesets on Pie (from the DPs) that are the cause of the problem. Currently (as in the last 10min), I've got my v3.7 kernel (the 8.1 kernel) working on Pie, just as the v2.8.2 has been (at least, it appears that way - I'll know for sure by tomorrow).... If v3.7 pans out, I am going to do the following;

1. publish the v3.7 build that works on Pie, which was for 8.1, but has a lot of changes since the July build. (that I'm testing now)

2. Then I'll Selectively revert/cherry-pick through all of the android Pie Marlin commits, avoiding the problematic commits...

3. I'll take all of those (non-problematic) commits and (re-)apply them to both kernel trees + LTS patchwork

4. Then build + Publish both v2.9 and v3.7 for you guys

The problematic stuff will get resolved (100%), but I see this as the best compromise and way forward, with limited time / resources.... Then I can work on the tricky bits and commit them back later (in a few weeks), when I have more time to do so...

again, sorry for any inconvenience ~ but it hasn't been too fun for me, either! ROFL. I wanted to smash things yesterday, today a bit better.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
So v3.7 seems to be running great, I did hit one bump ~ but a patch that I haven't applied yet from Pie kernel will fix it, other than that I haven't noticed any problems (just minor bits that should be addressed when I add Pie's patchwork"....

So, when I get home I'm going to try and get that stuff merged - give both kernels another whirl and hopefully post new builds. So barring any issues ~ at the very least I will have a new v3.7 build up that works on Pie ~ and if I can scrape together enough time, I might be able to get actual Pie builds up (We'll see, could happen late tonight, or maybe not until tomorrow ~ it all depends on timing and if I hit any issues).
[Google Pixel ROMs, Kernels, Recoveries, & Other De] matt99017d:
Awesome! Can't wait to try it out. Donyou have any data as to what kind of SOT you get with the new setup?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] almightysiman:
Sweet!eagerly waiting!:p
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
No idea, I've had too many other issues that I've been dealing with and life is really busy right now. In theory, android Pie should be better, due to some changes in how they are handling cpusets / task placement ~ but who knows, experience tells me that every major release of android has regressions and things don't get smoothed out until .1 releases....

The other thing is that SOT is entirely dependent on your own usage. on 8.1, with mediam/heavy use (which means everything but heavy gaming) I was getting 6+hrs, but in the last while I have noticed that my battery is starting to degrade, so it isn't quite getting what it used to (regardless of kernels).... Now, if your a gamer - SOT goes out the window, games like PUBG mobile ~ chew through battery, especially depending on GFX settings, etc.... So like i say; it's entirely dependent on usage / user habits.

Well, unfortunately, you're going to have to be patient, I still have a somewhat critical issue that remains unresolved (but everything else seems to be in good shape). I'm hoping to have another stab at fixing it, later today or tonight. (I'm pressed for time and trying to make some time to work on it ~ but, I've had a few previous attempts at it without success (I've spent hours and hours), which is all very annoying). I did however, get LTS and P stuff finished up ~ so when I do get this issue resolved, basically everything is caught up....

that said, I basically have no ETA ~ as I said a few days ago - I'm now super busy and will be for at least a week or two. Which sucks, but I have other responsibilities / work to do... That's why I was rushing to try and get everything done (which didn't work out). Maybe I'll get lucky and have an update later or tomorrow, but I may not for two weeks ~ I just don't know....

it sucks and i apologize, but it is what it is. I'm pretty much done stressing myself out about it.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
OK, so after some headaches and distractions:

i appear to have fixed the crash that has been blocking me releasing Pie kernels... it was a bit of a pain to fix, because the crash exposed other kernel bugs, so it was unclear, at first, what the actual problem was (and it's a bit specific to my kernel. ie: non-issue on vanilla marling sources...).

the crash was happening when using USB/otg... due to differeneces in the MD, block and driver/base of my kernel, i had to backport some code + fix the issue itself... but USB/otg seems to be working, as expected now...

soo, I'm going to test over the next 24hrs + import the needed changes for v2.9 (and give it a run too).

the upside here (bug fix aside) is that i also (as mentioned) pulled in the Pie related changes + LTS 3.18.118 *and* I've updated Swait (simple waitqueues) to match the never mainline implementation && i think I'm ready to enable boostbox for v3.7 too...

anyway, assuming no mor problems; tomorrow tonight I'll try to get Pie builds up...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Poebat:
Hello! Will this kernel work with LineageOS 15.1?

Thanks!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] bbender716:
Running great with magisk 16.7 on 9.0. Applied boostbox via root explorer and all is well! Will update if I run into anything. Thanks man!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
cool. yes, give it a good run. do let me know of any issues, observations, etc... i appreciate the feedback

while there is more work to be done, i do believe that I've taken care of any really critical issues on the initial release... later, I'll try n write out more details on boostbox and some of the other changes...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
v2.8 on the OP probably will (as people do use my kernels on custom ROMs... however, i only use/test with stock ROM)..

the above link to my v3.8.1 kernel may or may not work on 8.1, as it's really for android 9.0 - which is what I'm running...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Just a couple things that I didn't mention about v3.8.1 that I posted yesterday.

ref: https://xdaforums.com/showpost.php?p=77328332&postcount=837

ref: this build; https://github.com/nine7nine/Apps/raw/master/exns_eas_v3.8.1p_b325e69.zip

There are a couple of things that will seem wrong, or like a bug in EXKM.

#1 - under CPU section, you may have noticed that the min CPU freq isn't correct; e.g: showing a previously cached value or doesn't reflect what cpufreq is doing ~ this doesn't matter && is entirely normal / expected... You also cannot manipulate the min/max CPU values, either ~ userspace has been blocked from doing such things (this includes crippling msm_performance, as well).... Boostbox manages this stuff. it controls the min boosting values and handles boosting events. (it's the entry point, to change these types of settings).

#2 - You may have noticed that there is no traditional touch-boosting on v3.8.1 ~ this is very much intended. Perfd/msm_performance does crazy ***, like boosting the big cores to 1363mhz for a second or two, which is quite excessive... I've found that it just isn't really needed due to a few different factors on v3.8.1. (where threads/tasks are placed, which cpus they run on, boostbox, etc).

#3 - Currently there is some spam in logcat to do with Perfd being disabled (and also some other unrelated warning/errors that will be fixed soonish / A.S.A.P.... Some of it has to do with a few bits for P that I haven't pulled in yet, while there are other bits relating to my kernel ~ most are NOT critical issues, which is why I haven't dealt with them yet, since my time has been limited.).

anyway, no one has mentioned noticing any of these differences, aside from someone PM'ing me about #1.. But I thought I would point these out, for the observant / curious.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] kkjb:
Just in case the silence is bugging.... I have newest, but since it's daytime now will run and give data, just device is the day "phone". Thank you so much for your time and consideration..
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Poebat:
Alright, thanks! I'll give it a try.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Oh thanks, I really do appreciate the heads up. The silence is bugging. lol. but I've had a few PMs and I do have a friend (locally) that uses it, so it's not total radio silcence. ROFL... Yeah, give it a good run, let me know the good and/or the bad... any observations really. It's very much appreciated.

I'll be working to get any issues ironed out, as quickly as I can, for sure.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] kkjb:
So...I was running PPR1, Magisk 16.7, twrp 3-2-3.0, Tulsa Aroma Mods. Followed first couple posts to return to Stock. Nope looped to G (3X) tried long pwr,dwn to Triangle..(forget what this is). So did a Flash All bat with -W removed. Normal Install... 3.8.1 install, Magisk for root. I will some point do Shell script but for now, will leave as is. Tulsa Aroma Mods may have been Bootloop.

So my usage is really long screen off time. I found that Pie allows Ambient Display (double-tap+lift to check only) New Notifications toggled off. A great feature (for Me) is the auto Battery saver mode on battery causes Ambient Display to in-pocket mode not false on display, ie pwr button when in battery saver. When I want I toggle out of bat save mode.

So in case you wonder yep I would really like Battery Saver mode to cause kernel or a Knob like helper for reduced draw....But I already have asked that so just a thank you again....
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
yeah, not sure about some of the magisk (or xposed) mods out there, I've seen odd things happen (on stock too), so i avoid that kind of thing, or I'm very careful about what i use... it probably was the audio mod, but idk.

well, battery saver mode still does part of what it does and when the screen off, your battery usage should flatline... there wouldn't be any sort of boosting happening while the device is idle .

just out of curiousity, what is ''really long screen off time'?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] kkjb:
A gross example of my useage. 100% to 97 on 8 hrs bed stand.. bat saver on...94 bat saver off. Cellular is 30-60% rssi (strength) wi-fi on (project Fi) in day pocket mode 5 hrs 100% to 87 with 20 minutes display on and maybe 20 minutes SOT. Understand I keep above 60% or I freak out. If I thought batteries availability was better...... learned from Nexus 5x :( Stock kernel, Flash kernel about 2-3% better more aggressive low CPU speeds-time, and faster to deep sleep. Also typically only 3-4 step CPU states too. If I explained badly, sorry :)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
I think i got all of that...

That's actually helpful, as for one thing; I forgot to disable a feature, by default ~ that I use ~ but which has a power cost... but one that I don't mind, because it has other benefits.... It's likely one contributor, so it won't be enabled in the next build.... There's also a couple of other changes that I'm going to test now.

That all said, I don't think what you are describing is really indicative of anything, necessarily. ~ in as far as the part about 2-3% more aggressive to low CPU times. Stock (no idea about Flash) kernel is also doing really heavy, sustained boosts on every touch - which is arguably a bit excessive and part of the equation (so I'm not sure evaluating just the metric you are looking at is necessarily meaningful, without other considerations.)...

regardless, I need to test with the one feature disabled and another couple of tweaks.

I'll let you know when I have a build up that includes said changes...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] kkjb:
In my "overnight stand mode"--osm-:) same pwr use to stock 100 to 97%. In CPU spd steps as expected, explained mostly 307 + 1593. Big cores very little time, but a little more than stock. So now on to my day pocket mode 'dpm' :) touch mode response better than stock too what little I have experienced yet. Thanks again.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] almightysiman:
Hi,nine7nine.I have been running 3.8.1 on Android 8.1 for several hours.I know you haven't test it on 8.1 but I'll let you know that 3.8.1 is running smooth on 8.1 so far.One thing I notice is the initial setup is not applied at all due to the updated anykernel2 as you mentioned above.I want to ask,Will it affect the final performance of kernel?Thanks!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Yeah, I suspected that it would run fine on 8.1, but it's good to have some verification on that~ it's very much appreciated... No, it shouldn't have an impact on performance, not being applied ~ and at least it's using Schedutil by default (since i've removed "sched")...

I''ll get the init rc stuff sorted on the next build. I was planning to anyway while I had another stab at v2.9 and a few other bits applicable to both kernels, tonight...

I'll let you know when there is a new v3.8.2 build up...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Ah, cool. I didn't expect that there would be a huge difference. Next build will possibly have some improvements on this front ~ it'll take me a bit to get everything tuned. It's a new version of android, new features in use, etc... I'll tame it all though and get everything else on my list done

yup. touch response should be better, for a few reasons.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] kkjb:
My usage. Better than stock

So for my usage with a night...bed stand mode, and a day...in the pocket mode. Great results, Thank You very much.

I think the changes are a improvement above "incremental" really. Touch response is better, I don't like smoother - it isn't descriptive enough term.

A lower delay time is better, for my needs. Power is not any different than stock which is as explained. Pie on ambient display (enabled auto Bat Saver) is excellent for my in the pocket needs. So in other words your Kernel only add's to Pie experience. I haven't added boot operations either just as flashed. I don't like new recents screen experience, but then new for newness not for me.

Especially since I have 5 different flavors of Android. Not sure if the screen shots will help but thought why not.

Expectantly waiting for more :)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Good stuff. Yeah, I actually expect that I will improve power efficiency in the next coming weeks (I'm just getting started on PIE builds, as well as settling in with the large changesets of the last month or so.). Being on Par with Stock (while changing how cpu boosting / schedtune works) means that we are off to a good start, and i believe there's lots of room for improvement.... ~ It's also important to remember that I use various things in my kernel that come with overhead, as well. (finding a balance is hard).

On touch responsiveness / input latency ~ One reason that touch is more responsive has to do with force threaded interrupts ~ this is a feature (not used in stock) that force-threads interrupts (that are allowed be threaded) and turns them into a SCHED_FIFO threads (realtime priority scheduling class). The synaptics dsx driver that we use on my kernel becomes threaded ~ so automatically, it's going to preempt non-rt tasks && threads and/or RT tasks && threads which a lower priority (so in terms of "quality of service" ~ the touch driver is getting good service. lol)...

I didn't really add forced interrupt threading for the touch driver ~ I had other reasons, as some of the drivers on Marlin do benefit from it (although, this is an example of me adding overhead to my kernel. this kind of thing doesn't come for "free", there is a always cost).

anyway, I'm glad that it's working well for you.... and yeah, I'll get an updated build u, when I can....
[Google Pixel ROMs, Kernels, Recoveries, & Other De] duniecool:
Wow, 3.8.1 running great. Also, does the # ./boostbox need to be executed after every reboot or just the initial reboot?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
yeah, for now on reboots. it'll be fixed in v3.8.2 - I'll try to get an update up in the next couple of days that fixes it.. (along with other fixes and a few more bits from Pie pulled in).

Tonight I'm just too tired / mentally fatigued (from work) to work on kernels... 8pm and I'm pretty much ready for sleep. lol.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] almightysiman:
After two day usage,I am really impressed by 3.8.1 build.It is quite stable,smooth,and battery friendly.Enjoy every bit of it,Thanks nine7nine!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
thanks for letting me know. next build should be more battery friendly (as the pie changes are trickling in and v3.8.1 doesn't use adaptive battery, but v3.8.2 will - already does on my phone) + i have disabled an optimization (that i use) that would reduce battery efficiency (i use said feature, to allow rt processes to be unthrottled, if non-rt processes are all idle - it's a good feature formy own use, but i never intended to have it enabled by default - but is enabled in v3.8.1.).

so between the two changes for the next build, we should profit with energy savings.

EDIT: forgot yer on 8.1 - so you'lll only be affected by the default that i changed, not adaptive battery... still should see an improvement
[Google Pixel ROMs, Kernels, Recoveries, & Other De] HesThatGuy:
This caught my attention and now I want to try this out on my own kernel. Is there any other commits besides this one: https://github.com/nine7nine/Marlin_exns-eas/commit/909d13ce7a9d2d04fce2886020e4a995e27d176b that I need to add?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] bbender716:
When I run the boostbox scripts I get a bunch of no such file or directory errors ...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
No, there are two commits that are absolutely necessary ~ but off hand, I can't point you to said commits; i'm on my phone / not in front of my computer... I'll have a look when I am home and see if I can track you down the needed commits...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Um, I'm confused ~ I have no clue what you're doing, but you shouldn't see any of this output ~ AFAICT, it looks like you've tried to cut and paste the script into a terminal or something???

all that should be necessary is;

Open a terminal;

# su
# ./boostbox

that's it.... there shouldn't be any output, like your screenshot shows.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] bbender716:
I did that because running it the other way yielded similar results:
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
it looks like you installed the kernel before magisk to me.... or used some other method that didn't install my init rc. (which means those cpusets were never created, so it fails).
[Google Pixel ROMs, Kernels, Recoveries, & Other De] bbender716:
Weird. I flashed via franco's manual flash function in his app. Will reflash via twrp.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
deleted. - double post

for whatever reason, it's been doing this a lot lately. never used to.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
re-download the zip, flash it with TWRP.

This rules out any possibilities, as I did at one point have an issue in my init rc, that I fixed quickly.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
[MENTION=7309286]HesThatGuy[/MENTION]

"arm64: Allow forced irq threading"

https://github.com/nathanchance/lin...ff875bf#diff-ca525d7c27bbf1205f9e88a42d4ec474

"arm64: Mark PMU interrupt IRQF_NO_THREAD"

https://github.com/nathanchance/lin...e7ac21c#diff-ca525d7c27bbf1205f9e88a42d4ec474

You need both of these to allow forced interrupt threading to work on arm64 kernels.

That said; You may need other commits and/or hit other problems along the way ~ that'll depend on your kernel, drivers, etc ~ as sometimes forced interrupt threading doesn't play nice.... I may not be able to help you if/when you hit issues ~ I've got a lot on my plate right now, so not much time to invest in solving issues with other people's kernels or devices...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] HesThatGuy:
Thanks for showing me these, just to clarify before I start adding them into my source I also need this commit that I posted in my other comment right?

https://github.com/nine7nine/Marlin_exns-eas/commit/909d13ce7a9d2d04fce2886020e4a995e27d176b
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Probably yeah, but grab it from upstream/mainline;

https://github.com/torvalds/linux/c...fa0f022#diff-226adeeea37b71fe444620c6b96c8bbb

you don't want to be pulling commits from my tree, really. ~ there are sometimes modified or are dependent on other non-obvious changes/commits (and you likely won't know that) ~ Probably not in this case, but in others it could be a real problem...