yashsingh1/xdaforums huggingface dataset:
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] skinza:
Followed the above instructions

Ran no problem
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] xFirefly93:
Well. Disabling ZRAM can improve performance, because ZRAM uses CPU cycles for compressing and decompressing, and this can also save some battery (otherwise Sultan wouldn't disable and remove it from his kernel) but needs proper configured memory managment and what not for "compensating".

And NOOP have, AFAIK, less general overhead than CFQ because CFQ is made with IO fairness in mind which can, in worst case, starve some IO requests while giving other IO requests a "unfair" advantage.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
This! Both items increase device performance, with no downside that I've noticed.

I'll only add that Android does a fine job dealing without zram as-is. There's really no need to tinker with memory management, in my opinion. Just turn it off and profit.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
[MENTION=4793042]pkgnex[/MENTION] I found something else that may be worthwhile for "performace", which is BCL.

echo disable > /sys/devices/soc.0/qcom,bcl/mode

What is BCL?

BCL polls the battery monitor system for various values such as voltage, current and temperature through the battery. This driver is meant to help prevent possible reboots, but with it removed on several devices we have seen no issues.

The way it prevents reboots is by setting thresholds and when the threshold is passed or tripped, it will throttle or unplug cores, which is detrimental to performance(we have seen it on the OnePlus Two and Nexus 6 so far). With that being said, wouldn't you truly like your device to run at its maximum performance and let the real hotplugging and thermal drivers work properly?[/QUOTE]
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] xFirefly93:
[/QUOTE]

The specific sysfs path on Pixel 2 (XL) seems though to be..

/sys/devices/soc/soc:qcom,bcl

Just wanted to clarify that.

Isn't a change like this bad for the whole phone (specially for the battery and the SOC) if the thermal driver can't throttle when the temperature is far too high?

Or is it me that is misunderstanding something right now?
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
Updated, I forgot to change it.

I don't really know to be honest, seems reasonable to let the hotplugging work instead, but YMMV. Just trying to find "performance" tweaks. :)
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
I experienced lots of problems with BCL on my Nexus 6 - before I disabled it and the kernel dev's started changing the kernel behavior to not allow it, the phone would become a laggy mess as soon as the battery percentage got below 40%. It was truly awful - like running a device that was 3 years older!

That said, I have experienced no such issues on the Pixel 2 XL, nor have I heard of anyone else having them. My guess is that it is much less aggressively tuned on this device and almost never kicks in. I don't think disabling it will have any effect on performance.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] xFirefly93:
IMO.

I would rather recommend some "deeper" tweaking & tuning that affects how the CPU is behaving and being used, like adjusting how RQ_AFFINITY behaves, which reduces heat generation in the long run, and also improves battery life because of less wakeups and overhead regressions.

Take a look at my script (see attached ZIP file) that is for now WIP, but is adjusted and "optimized" for FlashKernel in mind as option #1.

Just as a test reference.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Thanks for helping the development and discussion! The stat interval and dump tasks vm settings are ones I haven't looked into much previously, but will... the same with the kernel modules.

I've assessed a lot of the other items previously, and here were my findings for your consideration and further comment:

nomerges = 0 was found to be better for performance on virtually every scheduler, from back in the Fanco Dev Team days up until even now. It allows similar requests to be merged and I believe reduces seeking by the IO scheduler due to having less unmerged items in the elevator queue. This was even found to be true on noop - setting nomerges to anything except zero actually reduced io benchmark performance!

iostats really has no effect. In theory, setting to zero should save some cpu cycles, but I've never been able to quantify any real-world benefit, and I like having iostats available for some debugging stuff.

rq_affinity used to be best at 2 on dual-core devices, but my testing with the Pixel 2 XL has shown it is actually best set to 1 (which is stock, I think). I believe this is because it keeps requests in the same cluster (usually LITTLE in the big.LITTLE architecture), but doesn't force it to a specific core, thus allowing the cpu's built-in cluster allocation logic to handle the requests in the most efficient way possible.

As for the other stuff:

swappiness reduction is always a good idea, but I run it even lower (5 or 10 if I'm actually using swap), and with zram off as in my script, it doesn't matter.

Be aware that oom_kill_allocating_task=1 can cause weird behavior if memory runs low, and I'd therefore avoid this - especially with all the memory management stuff Nathan and Sultan have been toying with. I've had it happen where with a lot of stuff open in the background, this parameter would not allow me to open another new app (it just kept getting killed as it was the allocating task - I would tap the app icon and nothing would happen!). I think leaving this at 0 allows Android memory management to behave more normally as it will kill whatever task is least-needfully hogging a lot of memory in the background instead of the app you're trying to open or execute, which I think is the preferred behavior for most users.

These are just results or anecdotes from my testing and experience... I've tried almost all of these in the past for the same reasons you are doing so now!
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] xFirefly93:
Thanks for the quick response, and I have taken notes on what you just told me. And I am more than happy to get a chance to help and contribute whenever possible, even if my stuff/changes is of the smaller scale. Haha..

Though.

Isn't better to keep nomerges at bay by disabling it all together (nomerges=2) as it was defined and set to in my script, mainly because of general performance and IO latency/overhead reasons?

Or I am misunderstanding anything, according to the information in this link?

https://www.kernel.org/doc/Documentation/block/queue-sysfs.txt
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
That's a great link - I use it all the time when looking into this kind of stuff!

I think the nomerges option is probably a trade-off; you're right that disabling merges should save some overhead by not having to check if requests can be merged (which is why I've tested it so many times)... but it seems that losing the merging makes the io scheduler queue less efficient. My hypothesis is that the scheduler has to spend more time addressing each request individually when there are no merges, and the overhead gain from disabling merges is more than eaten up by the loss in scheduler efficiency from not being able to merge like / related requests.

This is one tuning parameter I'm pretty confident about as I've tested it on several different occasions and devices over the years, always with the result being that leaving merges on (nomerges=0) results in faster io performance, regardless of the scheduler being used. Even noop uses merging at the block level, and I'm guessing there is a reason for that based on what the extensive testing has shown.

BTW, I think increasing the vm stat_interval may be a good addition to the scripts as you probably don't need this writing out every second... but I think 750 (12.5 minutes?) may be a bit of overkill. I'm thinking something more like 30 or 60 could be a good compromise.

Let me know if you find disabling oom_dump_tasks or the kernel modules makes a big difference - I'm guessing since the dump_tasks only happens on an out-of-memory condition, it shouldn't do much to save battery (since it should rarely ever happen anyway) and would only serve to limit debug data if there is ever a problem.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] xFirefly93:
I will try with setting every 'nomerges' line to 0 and see if I can see any differences regarding efficiency and performance. Otherwise, I will leave it either at stock setting (=1) or keep it at 2. Have to play around with it a little, before I decide my prefered value (based on battery drain, performance and efficiency).

Though, I think that disabling oom_dump_tasks and various kernel modules will have some positive impact on battery life because of less kernel wakeups (and whatnot). Even Nathan and Sultan have removed a lot of kernel modules in their respective kernels (yes, I have compared their respective kernels to the various modules that is "included" in both stock kernel and ElementalX).

We just have to find out what's working best for Pixel 2 (XL), shortly explained! :)

EDIT: I tried your suggestions and I have to admit that "enabling" nomerges (=0) and setting rq_affinity to stock value (=1) causes more UI hiccups/lags and performance regressions than it did good for the user experience, IMO.

I am going to try with having oom_kill_allocating_task set to stock value (=0) and see how my Pixel 2 performs.

Stay tuned.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
I completely agree that the kernel module disabling will have some positive effect on battery life - I'm just not sure you'll be able to notice. If you can, please let me know! I'll be trying them myself and will also report back. My understanding of the omm_dump_tasks, however, is that it only "wakes up" when the out-of-memory manager is triggered, which shouldn't happen often (or, hopefully, ever!), which is why I don't think it will affect battery life at all.

If memory serves - some blocks have nomerges=0 already, some are at 1, and none are set to 2; at least on the stock kernel.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] xFirefly93:
I think it is better to keep oom_dump_tasks at bay with keeping it set to 0 because the oom_dump is basically only needed if you are a app developer (partially mainly) attempting to fix OOM situations, caused by app(s) of yours thanks to memory leaks and what not, or a advanced system maintainer that needs access to every debug friendly line possible. The same with iostats - I rather prefer having it disabled, for close to the same reasons, as mentioned regarding oom_dump_tasks.

About nomerges being set to 2.. I think that this setting will give best everyday performance, with less possible amount of "tradeoffs". It is just trial and error, and what the specific user needs from him, or her, phone.

EDIT: I think that disabling kernel modules can have some impact on the battery life during idle/screen of mainly, to be honest. Not much maybe, but it is still better than nothing in general.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
The fun thing about Android and tuning it is that anyone can tweak it to their preference!

Your right that all the things you mentioned will save some cpu cycles and should therefore save some power; at the expense of you, or a Dev, being able to figure out what's wrong if you ever encounter problems. If that happens though, you can always just turn iostats/kernel modules/vmstats back on! My experience with iostats is that you can't possibly tell the difference in battery life by turning it off - It is like 0.000000001% of your battery drain - and I like to see my iostats occasionally to gauge how my device is running, so I leave it on since turning it off and on is more effort than I think it's worth. I still have to try the kernel modules and increasing the vm stat counter, though.

I'm also glad you're happy with nomerges=2. I don't have your phone in my hand, but every device I've ever tried it on (5+ devices at this point), showed anything other than nomerges=0 made no affect on cpu performance (objective benchmark data) or battery life (subjective tests over many days with many different people), but decreased i/o write speed (objective, variable test data) to a statistically significant degree (paired t-test p-value always < 0.10, usually < 0.05, multiple runs, many devices).

Maybe your device behaves differently than every one I've owned; and every one all the members of Franco's Dev Team had. I'm serious, it IS possible, and I'm not being sarcastic - stranger things have happened. Just be mindful of your potential confirmation bias when testing subjectively. It's easy to think/talk yourself into believing something makes a difference when it really doesn't... and to do this enough times that you end up with a script that actually makes performance or battery life worse due to all the unknown / untested interaction effects between the variables! It's happened to me, and virtually ever other modder / dev / tester out there.

This is why my current script isn't full of every possible tweak anyone has ever mentioned (try supercharger, L-speed, etc. if you want that). Only statistically-verifiable improvements or those agreed to by a multi-panel jury of evaluators in a blind test make it in!
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] sublimaze:
Thanks for not throwing everything including the kitchen sink into this script. I am not pointing to any particular dev/mod/script, but there is a lot of snake oil out there and if you install enough crap on your phone, some of it will inevitably be counterproductive.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
You're welcome!

I may have a small update release upcoming that takes some of [MENTION=8852292]xFirefly93[/MENTION] suggestions... pending some more testing.

Seems like there is some demand for turning off iostats, the vm_stat counter reduction makes sense (although maybe not as extreme as his script), and kernel module turn-off's seem pretty safe.

nomerges will stay as-is, and the oom_dump_output will remain on for the time being.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
New Version

Updated!

New version (94pks12)

File attached in OP, descriptive change log in 2nd post.

If turning off any of the kernel modules causes anyone issues - please post in this thread. It hasn't caused me any issues, but I don't use USB-OTG, etc.

Enjoy!
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] arvylas:
Tried this script for the 1st time.I'm with Pie stock rom and sultan kernel. Even though it definitely feels snappier after the script the idle battery life is significantly worse. I used to have a 2-3% drain overnight and after the script it climbed to 10%. I'll keep it for a couple more days to see if anything changes.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Try version 11 (still in the op) and let me know if it is any better. I've been having worse battery life and a few other hiccups with version 12 over the last day that I didn't see initially.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] arvylas:
BTW i disabled the zram disable since sultan does this already also i kept cfq sched since i like it better. I think the wakeup values might be a bit high and draining a some battery when idle.

Edit:

When i remove a couple of lines i don't get an output file. I'm less than beginner when it comes to Bash so excuse my ignorance.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
If you want to remove a line, just put a # and a space at the beginning of it. Less chance of messing something up ...
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] xFirefly93:
Sorry for being far too way off-topic now but..

Is it any chance that you may use Telegram for more private conversations?
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Sorry, but no.

You can PM me, though.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] arvylas:
As it turns out the problem was the solid explorer editor in android. So everyone be careful as to which editor you use. Notepad++ works for sure.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] {davros}:
i noticed slight battery issues with the 12 version. i figured i was using it more but I've noticed more today also...
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Something's up... but I'm not sure it's the script.

My battery life (both idle and SOT) has gone down in the latter half of this week, and I've been running without the script at all for a day-and-a-half now without it getting better. I'm pretty sure it's not Flash kernel since the only update was an upstream linux patch, and I haven't changed anything else on my device. IMaybe play-services was updated and is sucking battery again; who knows.

I'll continue to monitor this, but at this point all I know is that version 11 was fine. Version 12 may also be fine since it really didn't perform any worse than stock is for me at the moment.

All that said, If anyone has battery life concerns they think may be related to this script, please revert to 11 for the time being.

I'll post again here when it is either figured out or resolved.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
I haven't noticed too much of an issue with v12, I did add some extra kernel modules and things like:

echo 0 > /proc/sys/fs/dir-notify-enable;
echo 0 > /proc/sys/kernel/compat-log;
echo "N" > /sys/module/ip6_tunnel/parameters/log_ecn_error
echo "0" > /sys/module/service_locator/parameters/enable
echo "N" > /sys/module/sit/parameters/log_ecn_error
echo "0" > /sys/module/usb_bam/parameters/enable_event_log
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
New Version

Updated!

New version (94pks14)

File attached in OP, descriptive change log in 2nd post.

This update resolves any issues from last release (if anyone encountered any), and has slightly improved performance relative to prior releases.

Enjoy!
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] xFirefly93:
Check your PM inbox when you have the time for it, I've some suggestions regarding your next/upcoming release(s) of your script, [MENTION=4793042]pkgnex[/MENTION], that I truly think the folks/around here would like.

A lot.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Got your PM and am looking into your ideas...

Thanks!
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
New Version

Updated!

New version (94pks15)

File attached in OP, descriptive change log in 2nd post.

Credit to [MENTION=8852292]xFirefly93[/MENTION] for the improvements!

Enjoy!
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Schroeder09:
I don't see the magisk folder in solid explorer. Selecting "hidden folders" in the setting menu just says "no content here." Is this the right place? I put it here and I do have the swap torpedo magisk module already, but even after disabling that this script ENABLED my swap.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] xFirefly93:
Use the free FX filebrowser (and the root add-on) instead. Works like a charm and is 500 times easier to use.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Schroeder09:
Are there any downsides to that one when compared try Ed to solid explorer?

When doesn't it see the folder?

Does swbtorpedo need disabled for this to work?
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
That looks like the right place.

I'm afraid it's not possible that my script is enabling / turning swap on... that requires a different set of commands that is not in my script at all (it's not a toggle, you have to write opposite code stating "enable" and "swapon").

Can you ensure any kernel app you are using (like FK or EX) is not set to do anything at boot, that you have the osm0sis busybox magisk module and no others, and then reboot? Abput 2 minutes after boot, check to see if you get the output file in your base directory and if it says "success". If the output file is there and says it ran and if swap is still on, can you then go into the magisk manager app, look at the magisk log and post that screenshot as well? Near the end, it should say "late start service running" or something like that and then "94pks15" should be on the next line.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
I don't know for sure, but if your goal is to turn off zram, my script will do it without needing that module. It would therefore be unneeded at best and could cause a conflict in the worst case.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Schroeder09:
I already have solid explorer and I think I paid for it too. I'd like to keep it. Can I just move this file where it needs to be in twrp or make the folder like bryantjoplin said he did on page 1?
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Solid Explorer shouldn't be the problem.

I guess I'm not fully understanding your issue: Is the folder /sbin/.core/img/.core/service.d not on your device?

If it is (like it looked to be in your screenshots), please run through the troubleshooting steps I outlined in response to you earlier and report back.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Schroeder09:
I have that folder as shown in on of the screenshots, but on page one of the thread there is a screenshot shown where those folders are actually in a magisk folder. My mistake. Based on what you've said here I guess I do have this in the right folder with the righr permissions. The instructions say to delete th .txt file extension. Does it need replaced with anything?

I'm using ex kernel manager. Here's a list of advanced IO settings that are set to apply at boot. Could these be causing any issues? I do have th BusyBox by osmosis magisj module.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Yeah, the magisk folder in that screenshot went away - I think it changed with v15 or v16. You've got it in the right place, and just deleting the ".txt" as it looks like you've done is right, don't replace it with anything.

The IO settings could be causing the issue - since my script changes the scheduler to noop and those settings are for cfq (I think), it may be causing something to hang up and not run.

That's just my best guess, though.

Can you just turn off the advanced i/o stuff in EX, reboot your phone, wait 2 minutes, then see if zram is still on in the "memory" section of the EX kernel app? If zram is still on, open magisk manager, go to logs, then swipe over to "magisk" (not su) and see if it says the script ran as a late start service?
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Schroeder09:
On top of all this do I also have to change my IO scheduler to noop?
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
No. The script does that itself. It's just a theory that EX trying to enforce cfq and advanced settings at boot may be conflicting with the script trying to set it to noop, causing one to stop running or getting over-written.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
[MENTION=4793042]pkgnex[/MENTION] I also have: echo 0 > /proc/sys/kernel/compat-log; # stock is 1 after the dir-notify-enable option, have had both of these in my edited version of v14 for awhile. :)

echo 10 > /proc/sys/fs/lease-break-time; # stock is 45

echo 0 > /proc/sys/fs/dir-notify-enable; # stock is 1

echo 0 > /proc/sys/kernel/compat-log; # stock is 1
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] sruel3216:
Using your script with ElementalX too and the app is showing cfq also
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Noted!

I add things much more cautiously than many others...
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Is my script running (Check result file output and magisk log)?

Do you have EX set to do any things at start-up?