yashsingh1/xdaforums huggingface dataset:
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Yeah. It's tough to find things that actually make a difference these days!
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
New Version

Updated!

New version (94pks9)

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

Enjoy!
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Schroeder09:
Can anyone give me a little more instruction on how to use this? I'm running the pixel 2 XL with ex 1.06 kernel on April security patch. I have magisk v16. I have some launcher mods from tulsadiver and sharkie.

So, I download the file, cut it from my downloads, move it to the location in the OP (root/magisk/.core/service.d), and then what? Reboot and that's it? Does anything have to be flashed through magisk or anything?
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Pretty much. See my reply to your pm.

Download, delete the ".txt" extension, move to (root)/sbin/.core/img/.core/service.d, long press or highlight & settings in your file explorer to change permissions (0755 - -all reads checked, write for owner only, all executes checked).

Then just reboot - Magisk will run it as a late-start service script and the script will put a text file in your /sdcard directory (base of normal storage) stating if it ran right.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
New Version

Updated!

New version (94pks10)

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

Enjoy!
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
As per this post: https://www.androidpolice.com/2011/...-200-with-a-simple-tweak-hands-on-benchmarks/

I'm going to run *only* a script that changes the read_ahead_kb and run the same tests to see the results with 128/1024/2048/3072/4096. I tested the app they have, but seems to crash on Oreo, so am testing with https://play.google.com/store/apps/details?id=com.a1dev.sdbench
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Right on!

I actually just did this, which is why I changed it in v10. I used the app "AndroBench" which I highly recommend. I found that for most reasonable file sizes, the stock value of 1024 performed the best (slightly better than the 512 that used to work better on my N6 and prior phones). Higher values often work better for larger file sizes, but I'm rarely reading / writing more than 50 - 100 Mb at a time (and even then probably only for app installation), and this was the sweet spot for 1024, at least on my phone. Also, the difference is only a couple percent from best to worst level, not anywhere near the 10-30% that you could sometimes get in the old days.

Whatever app you use, just make sure to test different file sizes for each read_ahead value!

I'm interested to see if you find a different result.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
I'll use AndroBench, and test 64MB/128MB/256MB and post the results. ?

Edit: looks like 128 is best.

128 readahead
64MB
Sequential Read: 727.54 | Sequential Write: 220.60
Random Read: 173.34 | Random Write: 23.94

128MB
Sequential Read: 741.51 | Sequential Write: 220.52
Random Read: 168.86 | Random Write: 22.55

256MB
Sequential Read: 754.71 | Sequential Write: 222.51
Random Read: 168.80 | Random Write: 20.07

192 readahead
64MB
Sequential Read: 727.17 | Sequential Write: 196.42
Random Read: 172.77 | Random Write: 21.22

128MB
Sequential Read: 749.48 | Sequential Write: 216.58
Random Read: 172.09 | Random Write: 23.02

256MB
Sequential Read: 755.58 | Sequential Write: 220.50
Random Read: 168.63 | Random Write: 21.44

1024 readahead
64MB
Sequential Read: 722.42 | Sequential Write: 193.39
Random Read: 173.60 | Random Write: 23.62

128MB
Sequential Read: 741.81 | Sequential Write: 215.88
Random Read: 168.58 | Random Write: 22.91

256MB
Sequential Read: 754.63 | Sequential Write: 220.23
Random Read: 170.45 | Random Write: 21.16

2048 readahead
64MB
Sequential Read: 718.69 | Sequential Write: 186.72
Random Read: 154.34 | Random Write: 22.84

128MB
Sequential Read: 736.60 | Sequential Write: 217.65
Random Read: 168.64 | Random Write: 22.62

256MB
Sequential Read: 752.35 | Sequential Write: 220.76
Random Read: 170.28 | Random Write: 21.66

3072 readahead
64MB
Sequential Read: 712.35 | Sequential Write: 193.12
Random Read: 141.52 | Random Write: 22.42

128MB
Sequential Read: 744.97 | Sequential Write: 220.64
Random Read: 170.47 | Random Write: 22.30

256MB
Sequential Read: 745.18 | Sequential Write: 219.90
Random Read: 168.56 | Random Write: 21.0

4096 readahead
64MB
Sequential Read: 716.91 | Sequential Write: 218.42
Random Read: 172.18 | Random Write: 21.61

128MB
Sequential Read: 733.93 | Sequential Write: 221.44
Random Read: 170.94 | Random Write: 21.81

256MB
Sequential Read: 749.86 | Sequential Write: 210.90
Random Read: 167.07 | Random Write: 20.72
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Yes, it does.

When I did it I got 1024 to be best, so it must be device set-up dependent.

In both your data and mine, the maximum difference was less than 2.5%, so I'm thinking it's mostly just noise.

That said, if 128 tested best on your phone, there's no reason for you not to use it!
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
Yeah, I'll stick with 128.

I did find a few other things that could be added for noop sheduler:

echo 0 > /sys/block/*/queue/iostats

Also, net tweaks that may help:

Disable ping: echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all; # default 0

Disable Redirects (not a router):

echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects; # default 1

Don't accept source routing:

echo 0 > /proc/sys/net/ipv4/conf/default/accept_source_route; # default 1

echo 0 > /proc/sys/net/ipv4/conf/lo/accept_source_route; # default 1

Disable ICMP Redirect Acceptance:

echo 0 > /proc/sys/net/ipv4/conf/default/accept_redirects; # default 1

echo 0 > /proc/sys/net/ipv4/conf/default/secure_redirect; # default 1

echo 0 > /proc/sys/net/ipv4/conf/lo/accept_redirects; # default 1

By default, TCP saves various connection metrics in the route cache when the connection closes, so that connections established in the near future can use these to set initial conditions. Usually, this increases overall performance, but may sometimes cause performance degradation. If set, TCP will not cache metrics on closing connections.

echo 1 > /proc/sys/net/ipv4/tcp_no_metrics_save; # default 0

Set maximum number of packets, queued on the INPUT side, when the interface receives packets faster than kernel can process them.

echo 5000 > /proc/sys/net/core/netdev_max_backlog; # default 10000
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Interesting finds! Let me know if any of them seem to help performance or save battery.

FWIW I've turned iostats off before and found no difference in performance - it's a very low-overhead system function that actually provides very useful data if you ever need to track or debug your io performance, so I recommend just leaving it on.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
I'll see how it goes. I don't usually debug anything, and it may not make any noticeable difference in performance disabling the iostats haha.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] MrPhilo:
Reading through the pages and I can see LMK being removed. I'm assuming the ram management was still bad after the tweak?

Is there no way to atleast keep 10 apps opened in the background without reloading?

I plan to get the XL2 for the camera.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
The previous LMK tweaks really just served to increase RAM very slightly, at the significant expense of keeping fewer apps in memory - so the exact opposite of what you seem to be looking for. I don't think "tweaking" in the other direction would help you, either, as it seems that the RAM management kind of just is what it is these days.

I also think it depends on which 10 apps you want to keep open - if they are small, it seems Android handles it relatively well, but if they are large apps having 10 in memory might be a stretch. I have no problem with multi-tasking on the device, but I don't usually keep that many large apps open simultaneously.

You could always try keeping zram enabled (stock behavior, turn it off in my script) and perhaps even increasing the size of the zram partition to meet your needs (using a kernel management app, or similar), but I would try seeing how the stock behavior suits you before going down that road.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] EnIXmA:
Any benefits of using this script? Or is just placebo
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
There are some verifiable, real improvements over stock, but they are marginal.

So, I'd say it's worth running, but it isn't a life changing experience.

Try it and judge for yourself!
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
With all the testing [MENTION=4793042]pkgnex[/MENTION] and I have been doing, there is marginal benefits. Definitely not placebo.

At the end of the day, it takes a second to copy the script across, so why not?
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] EnIXmA:
Just placed the script in the magisk folder, set permissions and rebooted. How do I know it's working?
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] MrBrady:
There should be a new file on your internal storage saying if it was successful.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] EnIXmA:
If I don't want the script all I have to do is delete the file?
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Yes. Delete the file and reboot your phone, and you'll be back to where you were before.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] MrBrady:
You delete the file in .sbin (where you installed it). The file on your internal storage just lets you know it's working.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] rickysidhu_:
Hello everyone,

I placed the script in the service.d folder as I am rooted with Magisk, removed the .txt extension, set permissions to 755 and rebooted.

I don't see any text file in the root of my sdcard saying success or failure, there's simply just no file.

However, I noticed in my kernel manager app, my default scheduler went from cfq to noop. That tells me that something has changed, but I just wanted to confirm since I see no text file.

Thanks in advance!
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pa.pn2:
Same here.no file
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
The file "pks_script_result" should be written to /storage/emulated/0. Opening it will let you know if it was successful or failed.

It is a text file, but has no extension.

If your scheduler changed from cfq to noop, that indicates at least most of the script ran.

Check your magisk log in the magisk manager app (settings, logs, then swipe right for magisk tab). You should see "service.d: exec [94pks10]" near the end of the file.

If the magisk log says it ran, but you're still not seeing the output file, please let me know and I will have you try something that should get the file to output.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] rickysidhu_:
Yep, I see the script in the log (attached for your reference). If this means it is running successfully, I don't mind not having a file showing the script's output. However, if you want me to try what method you had in mind, I'm also more than happy to do so! :)
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
If you've got a lot of other modules or startup stuff going on, it may need to start a bit later.

If you can, open the script, change the "sleep 30" to "sleep 100", save, delete the .bak copy, and reboot again.

I think this should work for you, but after your phone boots up wait at least 2 minutes before even trying to look for the write-out file. :)

If you can do this and verify it works, you'll be good to go and I'll fix it in the next version.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] rickysidhu_:
Still doesn't seem to work. I've attached a screenshot of the location of the file as well as the sleep setting changed. My scheduler is also still at cfq, instead of going to noop like it was before.

I waited about 15 minutes before checking for a file to be on the safe side.

If it's too much of a hassle to troubleshoot this, I'm happy to wait to see if the next version you release changes anything. Thank you so much for the help:highfive:
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] azpatterson3:
[MENTION=4793042]pkgnex[/MENTION] thanks for the work. Every bit helps.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
A ha!

Thx for the screenshot. That location was deprecated in magisk 2 releases ago, so it's almost certainly your problem.

Place the script in /sbin/.core/img/.core/service.d, reboot and let me know if it works.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] rickysidhu_:
I navigated to that location and the file still showed it was there :eek:
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
It's a trap (ha ha).

I had the same issue when 16.3 dropped. It looked like it was there due to previous symlinks or something, but it wasn't working.

Here's what I suggest: delete the /Magisk/service.d folder in it's entirety. Then reboot. Then put the script in the folder in my previous post and reboot again.

Sorry if it feels like I'm giving you the run around, but this seems just like what happened to me a few weeks ago, and I'm really just trying to help. Thx for your patience!
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] rickysidhu_:
Haha firstly, you definitely shouldn't be thanking me, or apologizing to me - I should be the one thanking you for being patient with me and trying to help me out the best you can! Seems like it's working for the majority, so it's most likely something on my end. Much appreciated kind sir.

Secondly, I did have 16.3 installed previously, but went back to 16.0, not sure if that is playing a role in all this.

Thirdly, I tried what you suggested and still no luck. I even went as far as installing another root file explorer to see if that would make a difference.

Finally, I did some improvising and pasted the script in a run shell action in Tasker. When I ran the task, it was showing as continually running for an infinite time, so I just cancelled out on it. However, when I went back into my file explorer, I noticed the file showed up, and when I opened it, it showed the script ran successfully! I even went back into my kernel manager and saw noop was now the default scheduler.

I rebooted and kept note of the timestamp of the last modification of the output file, hoping the timestamp would update, indicating the script ran again post-reboot, but no luck. I went back into my kernel manager app and cfq was back to being the scheduler, telling me the script did not run after a reboot.

So all-in-all, seems like the only way I can get it to work is by running it in Tasker, even though tasker doesn't show the script has completed running (just continually shows it as running, even if I change the sleep number to a smaller value).

I'll continue playing around with it and maybe I'll get it to work, if not, I don't mind waiting to see if a future release could fix it. You've helped a lot and I couldn't be more thankful :good:
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Yeah, I think something with the late-start service timing in Magisk is the culprit. Sounds like the script starts to run, but then gets cut-off at random points and doesn't make it to completion. Perhaps the other late start stuff like viper takes over on your set-up. It could be that a system wipe would help (like at the next monthly security update, flashing the new factory images) if your transition from beta to stable and back messed something up.

But the infinite run in tasker shouldn't happen, either. It should look that way while the script sleeps for 100 seconds, but it should exit eventually, so that's either a tasker thing or there's something wrong with the script.

If you get some time, can you try just running it from a terminal emulator (make sure sleep is back at 100):

type: "su" and hit enter

type: "/sbin/.core/img/.core/service.d/94pks10"

(no quotes)

Let me know if it seems like it waits for about 100 seconds, then returns back to the su prompt, and if the output file gets created / scheduler changes.

If everything works there, then maybe increasing the sleep time incrementally would find when it runs or completes.

There's only a few things left to try at this point...
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] rickysidhu_:
The infinite run in Tasker was resolved by removing the sleep portion entirely (not sure if I was even supposed to do that), but I did run the task several minutes after boot, so I assume that shouldn't be an issue.

I tried Terminal, several variations of commands, including the one you suggested, and even ensuring permissions were correct by changing them within Terminal, with no luck. I just get "No such file or directory" or "Permission denied".

I think at this point, the best thing to do is waiting until the May monthly images are out, flashing those, and seeing if that makes any difference. You mentioned some changes occurred which led the script to not work for you when you upgraded to 16.3; that gives me the feeling it probably is me reverting back to stable.

I know I've said thanks a ton already but thank you one more time for all the help/suggestions you've been giving me! I'm quite patient so I don't mind for waiting for the May images, which are right around the corner anyway. Once they release, I'll flash, re-attempt the script and report back :)
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
It really sounds like the file actually isn't in /sbin/.core/img/.core/service.d BUT your file manager is showing it as being there due to the old symlink created from there to /magisk/.core/service.d in previous versions of Magisk. That's exactly the issue I was having, so I'm hoping it works out for you next week!

After you do the factory image upgrade, just make sure /magisk/.core/service.d doesn't exist (delete it if it does) and that the script is put in the /sbin location and then reboot. Let me know how it goes!

BTW, the sleep isn't necessary if you're running it after a boot from terminal or tasker, but it is needed for magisk to run it as a late-start service.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
Hey [MENTION=4793042]pkgnex[/MENTION] I have been reading up on a few things, I found this: https://wiki.ubuntu.com/ReducedPowerUsage

# Tweak virtual memory to conserve power when running on batteries.
echo 10 > /proc/sys/vm/swappiness
echo 0 > /proc/sys/vm/dirty_expire_centisecs
echo 0 > /proc/sys/vm/dirty_writeback_centisecs
echo 60 > /proc/sys/vm/dirty_background_ratio
echo 95 > /proc/sys/vm/dirty_ratio

In your script you have:

echo 5 > /proc/sys/vm/swappiness
echo 1000 > /proc/sys/vm/dirty_expire_centisecs
echo 2000 > /proc/sys/vm/dirty_writeback_centisecs
echo 2 > /proc/sys/vm/dirty_background_ratio
echo 70 > /proc/sys/vm/dirty_ratio

It may be a little beneficial to tweak these closer to the ones above? It could save some battery, considering the following is for "running on AC". :)

# Tweak virtual memory for running on AC.
echo 60 > /proc/sys/vm/swappiness
echo 3000 > /proc/sys/vm/dirty_expire_centisecs
echo 500 > /proc/sys/vm/dirty_writeback_centisecs
echo 10 > /proc/sys/vm/dirty_background_ratio
echo 40 > /proc/sys/vm/dirty_ratio

I've currently changed it to the following, see if I notice any slow-downs:

echo 5 > /proc/sys/vm/swappiness
echo 50 > /proc/sys/vm/dirty_expire_centisecs
echo 350 > /proc/sys/vm/dirty_writeback_centisecs
echo 50 > /proc/sys/vm/dirty_background_ratio
echo 85 > /proc/sys/vm/dirty_ratio

I've also been looking through some more tweaks, and have come across this a few times:

The normalized sleeper attempted to balance sleeping tasks and wait times to guarantee fairness when used in conjunction with FAIR_SLEEPERS/GENTLE_FAIR_SLEEPERS.

Bit of reading on sleepers, seems okay to disable and may yield performance improvement: http://lkml.iu.edu/hypermail/linux/kernel/1001.0/00468.html

# Disable normalize sleeper
busybox mount -t debugfs none /sys/kernel/debug;
echo NO_NORMALIZED_SLEEPER > /sys/kernel/debug/sched_features;
echo NO_FAIR_SLEEPERS > /sys/kernel/debug/sched_features;
echo NO_GENTLE_FAIR_SLEEPERS > /sys/kernel/debug/sched_features;

Seems the above code doesn't work though for some reason for the sleepers. *shrug*
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Turning off the expire / write back routine will definitely save a little power. I've tried that and it was barely noticeable. You probably don't want to turn them to zero and increase the dirty ratio parameters, though, for data integrity sake as it will mean you won't be writing to disk for very long periods of time.

The sleepers are interesting... haven't run into those before.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
Hey [MENTION=4793042]pkgnex[/MENTION] I was also looking at the kcal stuff, and stumbled upon this on reddit: https://www.reddit.com/r/GooglePixe...ation_report_on_pixel_2_xl_and_some_findings/ in which a person calibrated the display.

kcal has the following tunables:

/sys/devices/platform/kcal_ctrl.0/kcal - (0-256 0-256 0-256) - Controls Red/Green/Blue Multipliers
/sys/devices/platform/kcal_ctrl.0/kcal_min - (0-256) - Controls minimum RGB Multiplier value
/sys/devices/platform/kcal_ctrl.0/kcal_enable - (0-1) - Enables/Disables RGB Multiplier Control
/sys/devices/platform/kcal_ctrl.0/kcal_invert - (0-1) - Enables/Disables Display Inversion Mode
/sys/devices/platform/kcal_ctrl.0/kcal_sat - (224-383 or 128) - Controls saturation intensity - use 128 for grayscale mode
/sys/devices/platform/kcal_ctrl.0/kcal_hue - (0-1536) - Controls display hue - may have issues with msm8x26 in the higher values
/sys/devices/platform/kcal_ctrl.0/kcal_val - (128-383) - Controls display value
/sys/devices/platform/kcal_ctrl.0/kcal_cont - (128-383) - Controls display contrast

With a custom kernel, and display settings set to "boosted" I have added in the following, which sets it to: RED unchanged; GREEN 249; BLUE 226; MINIMUN RGB VALUE 5; SCREEN VALUE 130; CONTRAST 128.

I didn't change the red or contrast values as they're defaults.

#--------------------------------------------------
# Calibrate Display close to D65 (6500K) - Boosted
#--------------------------------------------------
echo 256 249 226 > /sys/devices/platform/kcal_ctrl.0/kcal; # stock is 256 256 256
echo 5 > /sys/devices/platform/kcal_ctrl.0/kcal_min; # stock is 35
echo 257 > /sys/devices/platform/kcal_ctrl.0/kcal_val; # stock is 255

I know this may not be for everyone, but I figured it cannot hurt.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Nice find, again. I'll have to try those out... although I admit to being one of those people who like the "saturated" profile pretty much as-is, and I generally like a slightly cooler (bluer) profile than 6500.

I doubt I'll be adding this to the 94pks script because it is a VERY personal preference thing, but I know there are a lot of people who like a D6500 calibrated screen. Maybe there's a kcal profile thread for Pixel 2 XL you could post this in if it's not already there? Or start one yourself!
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
I think I've seen the kcal profiles around on XDA, but usually used for EXKM etc.

I do know there's a bug with Oreo that if you reboot the colours don't change until you go into EXKM again, that's why I added them into the script. :)

I know it's a personal thing, and I don't mind manually adding it into the script. ? At least this way they do get applied on boot.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
New Version

Updated!

New version (94pks11)

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

Enjoy!