yashsingh1/xdaforums huggingface dataset:
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
[MENTION=7170589]Love4Taylor[/MENTION] [MENTION=8680413]shagbag913[/MENTION]

ok, so on P init.rc isn't being patched correctly due to it's "imports" being different. in AK2 I'm doing this;

insert_line "$overlay/init.rc" "init.exnoshadez.rc" after "import /init.usb.configfs.rc" "import /init.exnoshadez.rc"

import /init.usb.configfs.rc doesn't seem to exit in the P boot.img/init.rc that shag gave me. The only import seems to be; import /init.recovery.${ro.hardware}.rc ~ so obviously it can't patch init.rc and just fails.

So for P, it looks like my ak2 zip would need this;

insert_line "$overlay/init.rc" "init.exnoshadez.rc" after "import /init.recovery.${ro.hardware}.rc" "import /init.exnoshadez.rc"

not sure how magisk is patching init.rc on P and if doing this will cause a conflict ~ maybe you could try it out shag and let me know??? .... if it works then I could add a check in ak2 for which version of android is running and substitute the correct patching of init.rc for the corresponding/correct version.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Yeah, I'll try that tonight. Thanks for checking :good:

EDIT: [MENTION=7810360]nine7nine[/MENTION] I just extracted and checked the 8.1 boot.img/init.rc, and import /init.recovery.${ro.hardware}.rc seems to be the only import there as well?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
oops, bit of a braindead moment on my part. scratch that..lol

* what does your running P device show in init.rc? *

post the import lines, as they appear. here's my 8.1 init.rc;

import /init.magisk.rc
import /init.environ.rc
import /init.usb.rc
import /init.${ro.hardware}.rc
import /vendor/etc/init/hw/init.${ro.hardware}.rc
import /init.usb.configfs.rc
import /init.exnoshadez.rc
import /init.${ro.zygote}.rc
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Here's the /init.rc from P

import /init.magisk.rc
import /init.environ.rc
import /init.usb.rc
import /init.${ro.hardware}.rc
import /vendor/etc/init/hw/init.${ro.hardware}.rc
import /init.usb.configfs.rc
import /init.${ro.zygote}.rc
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
OK, so afaict P looks the same and the insert_line should be working the exact same way....

does the above show your kernel/ak2 (my kernel?) or is this stock (no init.rc patching, beyond magisk)?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
This is with no kernel. I'll flash a kernel here in a minute to see what it looks like, but pretty sure last time I tried it, it appeared to have added the import line correctly and the init.rc from ak2 was there so no idea why it wouldn't be working.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
if it shows my init.rc (or your custom init.rc) and sched is still being set (rather than schedutil) then either userspace or something in /vendor is setting it later on, most likely.

with 8.1 one of the vendor init.rc sets it to sched, I just switch it to schedutil after. (vs. editing anything in /vendor)...

anyway, let me know what happens when you try to patch init.rc on P - it's hard for me to verify or test without switching to P / wiping my device && I can't be doing that just yet.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Yeah, it's not adding the "import init.<kernel>.rc" to the /init.rc. If you have any ideas send em my way, I'll be on P for a little bit probably. I'll try stuff as well.

Edit: just to clarify, everything else seems to be normal (the custom init.rc is present)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Quadman:
Guys I'm on AEX Extended rom can someone please give me the flashing order to install the July kernel for Oreo? I'm really stoked to try this kernel and would appreciate the heads up.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
I can't help you, I only test/use my kernels on stock rom... shouldn't be that different flashing on your rom, but other users in the thread would be of better help than me.... so hopefully, someone else can pipe in....
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
[MENTION=1007992]everyone[/MENTION]

I'm hoping to push new builds tomorrow or monday.... assuming; I sort out the mac randomization issue && also resolve this last little immediate issue with a (schedtune based) driver that I'm working on for v3.6...

On the second part; for the last week or two I've been working on a driver that replaces "perfd"... It allows this kernel driver to manage schedtune more dynamically (schedtune is a key part of EAS and has pretty much everything to do with the Pixel's good performance && energy saving...).

Right now, my code is a (working) proof-of-concept and is working very well (not published yet though. will be soon)... It allows more granular control of schedtune / cpu boosting and performance/energy biasing and it is completely event-driven. The layout of schedtune's task & groups (CGROUP_SCHEDTUNE) is also different on my v3.6 kernel vs. stock kernel / userspace... With my driver / setup, it looks like this;

/dev/stune/audio/schedtune.boost
/dev/stune/background/schedtune.boost
/dev/stune/foreground/schedtune.boost
/dev/stune/gfx/schedtune.boost
/dev/stune/rt/schedtune.boost
/dev/stune/top-app/schedtune.boost

(this requires extra setup for cpusets + schedtune, but is already handled/working/tested in AK2/magisk).

The gfx and audio schedtune task cgroups don't exist outside of my own kernel use... I use these groups hooked into certain events (places/drivers within the kernel) to allow performance biasing different types of workloads. (I'm an audio guy ~ so being able to use schedtune more effectively to prioritize my audio stuff is great ~ but likewise; it's also possible to bias gfx pipeline or anything else)...

There are a number of tunables, which should (eventually) allow for creating different energy and performance profiles and there are already a number of events that can be configured via sysfs / modparams... right now, my module params are a bit overkill ~ but I need them for testing purposes, some won't end up being exposed to users...

So assuming today's build (running on my device) pans out, is reasonably good on energy consumption vs. performance ~ I should be able to push out a release for people to test....

After a few more revisions + a week or two of testing ~ my plan is to rebase the driver and all of it's dependencies on msm-3.18-eas ~ so that other devices / kernels could also use / pull in the driver, if they wanted to... It's obviously only been tested on EASv1.5/my kernel - but I don't see why it wouldn't work on say; stock marlin kernel (which uses EAS/schedtune, as well) or non-pixel devices that utilize EAS/schedtune.

anyway, I'll have more info on this soon && when I push a new build for v3.6 I think I might do a bit of a write up on features and such - because I'm not sure if I've ever really done that yet (and being as in the last while it's picked up a lot of features), it might be a good time to do that.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] BarackMitzvah:
Lots and lots of things I don't understand, but am excited nonetheless!

The write up would be absolutely lovely, especially if it'd help users tune the kernel to their liking in EX Kernel Manager. For now, I leave everything as default except I change the readahead value to 1024 KB and audio high performance -> ON.

Keep up the badass development nine!

We all love you for it ?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
ah, for the most part; the thing that matters is the device works well. The details are always complicated and while interesting for some, unnecessary to know for most end-users.

Well, the new driver / schedtune boosting scheme will have some knobs/controls, but I'm planning on adding a global control to bias energy saving vs. performance... The problem with having a lot of tunables in this driver - is that it's easy to mess things up, meaning things have to be done in a certain way... ~ to avoid starving processes, jank or other issues like that....

The idea would be to allow users to dial back performance for energy biasing, if they wanted to, without having to know how every knob/control works ~ just by tuning one or two controls.

On a more general note: I very consciously avoid adding a lot of controls for users (or even myself.... yeah, I don't change anything - if I change something; it probably becomes a default)... I tend to think that things should just "work out of the box" and not require a lot of tweaking...

the other thing is that many added features in v3.6 aren't necessarily user-defined or controlled, it's more likely to be something internal to the kernel itself.

thanks man....

------

[MENTION=1007992]everyone[/MENTION]

I won't push builds today, as while I sorted out the one issue, a couple others cropped up (one of which I just fixed now, one that I'm working on fixing right now)...

I thought I'd be ready today, but I'm not and I don't want to push out v3.6 prematurely (ie: I don't want to have any dumb/annoying issues. lol)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] kkjb:
The idea would be to allow users to dial back performance for energy biasing, if they wanted to, without having to know how every knob/control works ~ just by tuning one or two controls.

Yes-Yes-Yes

This would I believe get more users, I had to experiment and found out don't touch the controls dummy. I though a little tinkering would get better Sleep Mode = energy savings but learned to just leave alone and use Battery Save mode for better sleep = power conserve response.

Ex Manager energy flag one button I thought was the best but with experimentation found with Battery Saver = on, Ex managet leaf button = on worked the best for deepest sleep, battery savings.

I really would like the one button approach for myself, then I could experiment more with out having to twrp back to back up.

Thank You very MUCH for all your work.

Jack
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
hey jack,

glad you like my idea... I generally believe that the K.I.S.S principle should be used here.

well, with the code i'm working on now, ''battery saver'' actually becomes a no-op (no operation aka: does nothing) because it uses ''perfd'' (which I disable and let the kernel driver manage things)... in practice, this is fine, as boosting only occurs when needed && on idle or sleep ~ cpus will maintain lowest possible frequencies (this is also true when the screen is on, when there aren't any interactions happening that cause boosts)...

so initially having a knob to globallly dial back boosting, should result in power saving, without any complexity or knowledge required is ideal... * I may try to get battery saving hint working with the driver though...

there's a couple other things that i'm working on (new driver aside) that should be helpful too ~ some changes to the cpuidle driver (which could he useful in keeping the device cooler and possible power saving) and i'm also going to be updating cpufreq driver, so that I can unstub (use) the fast frequency switcher (which should reduce overhead) in schedutil ~ this stuff will probably land in v3.7...

...while v3.6 is mainly focused on the new schedtune boosting scheme and new driver to replace perfd... (and also re-tuning a few things in the kernel (e.g: my.current running build has a power saving of roughly a 4% per hour - while playing PUBG mobile (which is a pretty heavy/intensive game)...

hopefully after evaluating another battery cycle or two && also resolving the last two issues will allow me to get new builds out very soon...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] BarackMitzvah:
Assuming you use nathanchance's stable kernel source, he merged in up to version 3.18.116.

Hope all is well, current non-dev kernel running like a champ!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
All, is in fact, well. (Thanks!)

Yeah, no worries, on the next builds LTS will match whatever the current LTS is at that time (3.18.117, probably)... A couple LTS releases doesn't mandate me updating builds, they can just be included when I'm publishing builds on monthly release and/or if I have other compelling reasons to push updates...

mac randomization will also be fixed in the next builds.

I've also been busy working on other things, mainly changes for v3.x ~ which over the last couple of weeks; lots of changes are on-the-go... there's just a few minor issues to resolve with that ~ I had basically finished my new boosting driver, only to have to turn around and redo parts of it, as one of it's dependencies just had a big rewrite ~ I've reworked the driver now (as of yesterday), but now I have to run it through a few battery cycles / test... I basically have 2 minor issues to deal with... after that, i think it's in reasonable shape...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Hey nine, just wanted to let you know that I keep the latest boot images here, I know you ask for the boot IMG sometimes so figured it'd be helpful. I usually upload the newest images within an hour or two of the monthly security updates.

Also, nice work on your driver. I had a peek on github and although I don't understand it yet (still learning C and the kernel) it looks impressive :)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Hey Shag!

perfect, thanks. yup, always need Marlin's boot.img. appreciated.

The work is ongoing / not quite ready yet ~ I haven't had as much free time, as of late, as I would've hoped to have (not a huge deal though, I'll get to it).... A couple of things I'm working on right now / tonight + a fix so that the kernel compiles correctly when the driver is not enabled... I'm hoping this weekend, or maybe one other night this week I can make some more progress and actually get it ready to enable by default...

The other thing is that I'm kind of working on a bunch of other/different stuff. ~ git commit history reflects some of that (80 or so commits this month, not including any commits that have vanished due to forced-updating my branches).

Lots of new features in the kernel, some upstream stuff needed and lots of other stuff to finish up on and get committed.... I'm also gearing up to do more serious compiler optimizations... Namely; getting GCC's PGO (Profile Guided Optimization) working with my kernel sources. (I've got a really good start on this, but currently hit a bit of a ''catch-22'', so it might take a bit to get it resolved. not sure yet).
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Actually these are sailfish boot imgs (I have sailfish) I could always upload marlin boot imgs as well.

Sounds awesome! Your kernel is definitely much different than others (in a great way), very impressive. Can't wait to try out these new features.:)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
I wouldn't worry about it. there's always a marlin user or two who are good for it. sailfish, I obviously have.

hopefully, it will be awesome. boostbox, when finished should be pretty good. (still a lot of playing around /testing. ie: what's committed isn't what's running on my device - I have other patches that I haven't finished or decided on) ..

i'm also very excited about getting PGO working (I have it working fine in Archlinux), but these arm64 android kernels require a lot of extra work... and the issues i'm having mostly have to do with upstream (linux and gcc, but i'm sure they will get resolved)... related; I have LTO optimization is working nicely, only a few bits to finish yet ~ and i'm glad I have 16GB of RAM, as it sucks up a lot of memory during compilation. lol...

Also, still gonna try to update cpufreq + implement the fast frequency switcher too (i'm part way done the work, just taking a break.)... schedutil has way less overhead when using it... the sugov threads really only should be used for the slow path, rather than being used all of the time.

thanks! yup, my kernel is quite different. idk, I think i have different design goals than everyone else and I've been picking away at it for a long time. ~ most of which has been actually changing the core kernel internals (as opposed to adding a lot of schedulers, drivers,etc.)... in the long run it just makes supporting things i'm interested in much easier to implement/use... it's never ending though ???
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
I decided to go ahead and start uploading marlin images as well :) sailfish/marlin boot/vendor images here. I should get them uploaded as soon as the factory images are released ;)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] BarackMitzvah:
For all of you like me who've been holding off on using the dev branch kernel until Android P is released, rumor has it we'll get it around the 20th! Link
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
kool. thanks...

that's not a rumor. every new android release happens around August 20th. (always on a Monday)...

I'll be flashing android P this weekend most likely && applying all of the P related patchwork, etc... that'll give me a week or two test things...

I just have a couple of things that i'm going To try n get done before wiping my device; a bit of work on boostbox && I plan on reverting all changes to RCU, followed by upgrading RCU (proper) and then (re-)applying all of my out-of-tree / downstream rcu changes on top. fun.

luckily, I have the day off today, so I'll probably put in some of the above work on that today (well, not some... I'll do all of it probably... lol).
[Google Pixel ROMs, Kernels, Recoveries, & Other De] ztotherad:
even though you don't have to, thank you for keeping us up to date on the kernel! can't wait to run it!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
deleted
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Ah no probz! thanks!

I actually like informing users, so that's great that you appreciate it.

The RCU changesets will be the last big invasive changesets merged before P support ~ it's something that I've wanted to do for a while, but it's a little daunting. ie: I'm only into it as far as upstream/linux-4.2 ~ which is around 140 commits to RCU => by the time I finish it'll be around 200 commits ~ and I will almost certainly have to do a bit of surgery, re-integrating whatever Google/QC and my own changes that will need to be re-applied, possibly fixing call sites, if/when needed too... So not really fun to be working on ~ but it will improve RCU a lot && I should be able to take advantage of some of the newly added functionality...

taking a break now (as i'm past the 50% mark && this is really boring, repetitive work), but I shouldn't have any issues getting it finished today/tonight... then I'll get it all working/running + committed..

I'm also going to add a few things from my dev kernel into the v2.x kernel. Namely, updating binder, ion, etc to match v3.x... There's some bug fixes, compiler fixes, etc to be added && I'll probably bring over LTO support too.... (but this stuff is all simple cherry-picks, so easy-peasy...).
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Nailed most of this! ... still testing, so haven't committed it yet ~ but 200+ commits later + numerous related fixups within the kernel (they were interesting and a few unexpected bits to resolve) ~ But... it now boots and is working, as expected...

So I'll test overnight, probably get it committed after that, then look at P support - assuming no problems crop up, I'll flash P on Saturaday or Sunday. Light up support on both kernels... ~ no ETA, but obviously I will be ready for the Official Android P release.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
soooo...

the rcu update and related changes seem to be working out well! which is a big sigh of relief && I believe it will be added motivation to get some other parts of the ''core'' kernel updated (namely, the rest of MM, cpufreq, etc). ~ although I won't be starting on this until after P launches...

I've got everything committed now. rather than having 20 reverted commits && 220 new RCU commits + a number of commits fixing all of the relaled code, I consolidated everything, down to a handful of patches;

https://github.com/nine7nine/Marlin_exns-eas/commit/4708a6d80103d76964e9f9b84b7c2074a053c1f7

https://github.com/nine7nine/Marlin_exns-eas/commit/442ea61622002e42f86df6c74d9e75eeb9eef6ad

https://github.com/nine7nine/Marlin_exns-eas/commit/109039e1468cb896d31423dc9afeb7382525d138

it may not look like much, boiled down to a few commits, but it was actually a lot of work... afterwords, I re-applied the downstream related rcu stuff...

I also tried to make it clear that some of these changes may be specific to my kernel (meaning 3.18 kernels may lack some dependencies. aka: not a ''general'' 3.18 backport).

i''ll most likely flash P on my device late tonight or tomorrow ~ as I am testing a couple of changes (since yesterday) and I'd prefer to not swap in new firmware just yet (throws testing out the window)... but it'll all come together fairly quick now. ?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] bbender716:
Been using P as a DD for awhile now and you're in for a very pleasant surprise! Thanks for all you do!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
not really; i've already used P (just wasn't running it as DD). the lack of a system-wide dark theme / no substratum means a very significant downgrade for me.... none of new features make up for it, really... I also don't use pixel launcher or the majority of Google's apps and services, so some new changes have very little impact on me....

I'm mostly excited that they ditched adaptive brightness - which was junk, didn't work properly && drained battery / always had to disable it. and there's a few under the hood changes that are good too...

I'll probably be more interested in 9.1, than 9.0, tbh. the dot 1 releases are always way better, IMHO.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] BarackMitzvah:
Android 9.0 Images Released

Say WHAT:

[IMG="Google Factory Image Website"]https://i.imgur.com/h3ObJHo.png[/IMG]
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Yeah, I saw the announcement on Reddit.

They said they are "rolling it out" over the next couple of weeks, I'll probably get updated builds up tonight or tomorrow (depends on free time). i'm mostly ready to go, so....
[Google Pixel ROMs, Kernels, Recoveries, & Other De] BarackMitzvah:
Awesome! Thanks nine, you the man
[Google Pixel ROMs, Kernels, Recoveries, & Other De] armando_rod:
Btw, substratum works with root since a few weeks. Sai has been uploading apk in the Telegram chat
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Actually, the 4.2 ones were super easy to merge... I'd call them 'low hanging fruit'.... the changes were non-invasive, compared to changes for eas, sched, etc (stuff I grabbed from op5 eas)... getting dynamic stune boost to work, was also a pain. it wasn't written for our older kernel and *we didn't have cpu-boost kernel module in our sources - so I had to track down the supporting code, then fix it all up to get it working....

the only kink with keeping the 4.2 merges may be that i think they ae affecting how battery usage is being calculated, like it's not updating as fast (?), i'm going to test for the day/night and see for sure though...

not sue i notice the boot speed due to my sched_cfs_boost change - but it definitely boots faster than elemntalx or other custom kernels that i've tried, might be a bit faster than stock... i did follow all of google's docs on how to attain good boot timrs though.... snappy boot regardless ??