yashsingh1/xdaforums huggingface dataset:
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Odd. Did you delete the .txt extension on the file? Otherwise, maybe a bad download?

Can you re-download it and try just executing it from a terminal emulator (making sure you run "su" first)?

Only thing I can think of is that the 100 second sleep might be causing something else you're running to not execute and hanging everything up. Do you have any other scripts or modules running that might help me figure it out?

Glad it's working! You shouldn't expect any huge changes... maybe just a little "snappier" performance and possibly better battery life from the VM stuff. A 5% improvement is about the most I would expect.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
Strange, I downloaded it on my phone and copied it into the magisk folder and it worked.

Must of been a borked download.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] otonieru:
I run nothing too fancy i guess.

Am on march security update, Kirisakura 1.1.0 with EX kernel manager for color adjustment. I do set my I/O to maple though, if that matter

Other than that, i have xposed & dolby installed.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
It happens. Just glad it's working for you now!

Nothing in your first line concerns me at all as I've run those as well and haven't had any issues.

I would bet that xposed or Dolby are conflicting somehow - especially if they are being installed through magisk post.fs. I know a lot of dev's who say all bets are off when it comes to playing nice with xposed.

I'll be honest, I'm almost certainly not going to be able to resolve a conflict with xposed or other modules - I apologize for my lack of skills / time on that one.

If you really want to run the script, I would suggest maybe trying the magisk init.d injector module and putting the script there. Failing that, you could just run it manually after booting up - either via a terminal emulator (which would be kind of a pain, I know), trying to automate it with a script manager app (I've used "smanager" in the past, not sure if it has been maintained), or maybe using a scheduling app like Tasker.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
Wiped my phone today and flashed Resurrection remix, flashkernel and magisk.

The script is running fine. :)
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Megaflop666:
Good stuff. Thanks.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
My pleasure!
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
I'm going through / modifying your script, I noticed:

echo 5 > /proc/sys/vm/swappiness; # stock is 60, don't need swap but 0 is risky if swap is enabled

However, just under that you disable swap, so swappiness would be better set to 0, correct?

Also adding a few other little bits and pieces, will throw it up on Pastebin or something for you to suss out when I've finished.

Edit: Updated with ipv4 stuff and all here: https://paste.ee/p/zQmmO

Edit: Link updated
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Hey, glad for the back-up! I'll take a look at your file tomorrow.

Yes, you COULD set swappiness to 0, but since I have swap turned off, it doesn't really matter (off is off, after all!), and this is actually kind of risky.

The reason I recommend setting it above 0 is in case you ever flash something / load a script / run an app that turns swap back on, having swappiness set to 0 can actually be really unstable. It's safer to just leave it at something really low (like 1-10) so that if swap is ever turned back on it will still rarely be used, but not so low that it will cause issues like reboots you can't figure out.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
Oh right! that makes sense, so it's set to 5 *if* swap gets turned back on, gotcha!

Still reading up on some VM / FS / IPV4 stuff at the moment, no doubt I will have some more little things to add.

I updated the original link to the stuff that I've added. :)
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
I downloaded the link, reviewed your changes and additions, and will be testing them out later this morning. At first blush, here are my thoughts (subject to change after testing):

- First, thanks again for doing some research / legwork and contributing to the effort!

- I'm particularly interested in some of the kernel and network tweaks you added - although I'm admittedly concerned about disabling kernel panics; I think you

want

the kernel to be able to panic when things start going sideways.

- The entropy changes will likely not be noticeable, and the LMK stuff has been discussed ad-nauseum already - your values are so close to stock that I'm not sure you should bother.

- The dirty_ratio and vfs_cache_pressure increases will not be noticeable, but there is a possibility that setting dirty_background_ratio as high as you did could cause some latency issues in certain situations.

- I'll be doing some performance and network benchmarking to evaluate the kernel/network tweaks, as well as some subjective feel tests I like to run, so it might take a while for me to sort it out!
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
I figured I would disable the kernel panic stuff, because if the phone is going to crash, it's going to crash.

Yeah, I was thinking about removing the LMK stuff and just keeping it stock.

I was aiming for a little more battery, from my understanding those dirty_ratio and vfs_cache_pressure may help.

I've not run any benchmarks, just did it up and set it when I was at work earlier today.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
I honestly don't know what turning off the panic stuff might do - maybe nothing, but it's outside my comfort zone. If it seems to make the phone faster with no ill effects, then I'm all for it!

My understanding is that raising dirty_ratio and dirty_background_ratio may save some battery life (less write-outs to disk), but increasing cache pressure does the opposite (writing fs cache out more often). The trade-off with d_r and d_b_r being set high is that when the system does write out from memory to disk it will be a huge amount of data and your phone will get really laggy during the process. This is somewhat mitigated because the dirty_expire and dirty_writeback parameters force periodic writing out data anyways, but I already raised those values to save some battery life (not having the kernel writeout routine wake up as often). In any case, the effect of VM parameters on battery life is minuscule.

I'll let you know what I find through benchmarks and usage scenarios later today.

Edit: Benchmark results attached!

- I ran GeekBench 4 and a network speed test (since you're playing with the IPV4 stuff) 5 times with each script (94pks6 and your pastebin file). Every test was run the same way (same parameters, server), order randomized, with a reboot after each test, followed by a 5 minute settling / cooling period. I computed averages and ran a 2-sample t-test (p-value below 0.05 is very likely statistically significant, below 0.1 probably is, over 0.30 is very likely not).

- The result is that your changes made the network down/up speeds 33% and 17% worse, respectively, with the 33% download degradation bordering on statistically significant. The pings were virtually the same, but your script seemed to produce more jitter (variance) in the test to a very statistically significant degree (78% worse). None of the performance tests showed anything close to statistically significant, and were all just noise of .0027 (0.27%) or less, either way. I don't think running more tests would change the result much except to lessen the statistical significance of everything even more.

I'll run with your script for the next day or so to see if anything feels different subjectively.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
Well, that is horrible results. Stick with your OG script. ? Haha. I honestly thought the network things would make *some* difference after reading up about them.

Sorry for wasting your time.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
It wasn't a waste of time!

My subjective evaluations are convincing me there is something worth hanging onto here. My phone feels a little snappier and more fluid, especially through animations and such. Although page loading when browsing and file downloads seem a little less quick (validating the benchmark results).

It may be that the network stuff wasn't that hot, but you hit on something else. Or, maybe you were just turning too many knobs at once. Or, turning them too much.

I'm going to go through turning off one "section" at a time to see if I can determine a performance difference that way. If so, I can drill down from there.

If you could do the same - maybe trying only one or two of your adds at a time - and let me know if you stumble on anything I'd appreciate it.

It could be a wild goose chase, but nothing ventured, nothing gained, right?
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Scott:
I would remove LMK, "dirty_ratio", "vfs_cache_pressure" settings.

This phone does not suffer from slow DB writes and/ or a slow nand. On some really piss poor devices with ultra slow nand (think Asus TF 101), then the dirty ratio and cache pressure could help produce significant better performance. More cache, less disk writes = faster system. However, in the case of this phone, I don't think adjusting the cache will make any notable improvements.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
Are you just using the speedtest.net app to run the speed tests?

I might look into the network stuff a little further.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Yep!

I've been looking into some of them, too... we should compare notes in a day or so.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
I think I might remove everything out of the script, and just keep the networking stuff and work on one section at a time.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Good plan!
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
So, I think I've got your network settings at least back to parity with mine - maybe a touch slower ping but potentially even better upload rates. Here's what I changed:

netdev_max_backlog to 65536 (a value I saw online in a couple places)

somaxconn to 1024 (a value I saw online in a couple places)

rmem_default to 25165824 (a value I saw online in a couple places)

wmem_default to 25165824 (a value I saw online in a couple places)

tcp_ecn to 1 (should reduce congestion both down and up, maybe this was the key in improving upload?)

tcp_max_syn_backlog to 2048 (abased on what I read, stock is too low, your value probably too high)

tcp_timestamps to 1 (back to stock to avoid congestion issues)

tcp_tw_recylce to 0 (back to stock - everything I read said not to change this, and it is removed from newer kernels... tcp_tw_reuse is OK to set to 1, but not this recycle one)

I think the tcp_ecn may be the key... stock (and my script since I don't change it) are 2, meaning that congestion adjustments should be made for downloads. Setting this to zero like your first script does no congestion adjustments, and setting it to 1 like I did above makes congestions adjustments for both download and uploads.

Since I found scripts with 0 was worse than 2 for downloads and 1 was better than 2 for uploads, it seems like too much of a coincidence to not be the culprit since turning this flag "on" for either down or up improved the result correspondingly.

That said, if this is the key then maybe setting it to 1 and reverting most of your other changes is the answer - except perhaps tcp_tw_reuse and tcp_max_syn_backlog (but halving or quartering your initial value).

Let me know what you find.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
Interesting about the ecn stuff, I found some stuff online saying having the default as 2 can break routes, as per this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=117745 and https://arstechnica.com/civis/viewtopic.php?f=16&t=621335

I found conflicting information about the rmem and wmem, so decided to leave them out.

Here is what I currently have at the moment, I've been reading but have yet to test it.

#----------------------------------------------------
# network tweaks
#----------------------------------------------------
echo 1 > /proc/sys/net/ipv4/tcp_no_metrics_save; # stock is 0
echo 10240 > /proc/sys/net/ipv4/tcp_max_syn_backlog; # stock is 128
echo 1 > /proc/sys/net/ipv4/tcp_mtu_probing; # stock is 0
echo 2 > /proc/sys/net/ipv4/tcp_synack_retries; # stock is 5
echo 1 > /proc/sys/net/ipv4/tcp_rfc1337; # stock is 0
echo 15 > /proc/sys/net/ipv4/tcp_fin_timeout; # stock is 60
echo 1024 > /proc/sys/net/core/somaxconn; # stock is 128
echo 65536 > /proc/sys/net/core/netdev_max_backlog; # stock is 10000
echo 25165824 > /proc/sys/net/core/optmem_max; # stock is 20480
echo 5 > /proc/sys/net/ipv4/tcp_keepalive_probes; # stock is 9
echo 30 > /proc/sys/net/ipv4/tcp_keepalive_intvl; # stock is 75
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse; # stock is 0
echo 0 > /proc/sys/net/ipv4/tcp_timestamps; # stock is 1
echo 10240 > /proc/sys/net/ipv4/tcp_max_syn_backlog; # stock is 128
echo 0 > /proc/sys/net/ipv4/tcp_ecn; # stock is 2
echo 1 > /proc/sys/net/ipv4/tcp_low_latency; # stock is 0
echo 2 > /proc/sys/net/ipv4/tcp_syn_retries; # stock is 6
echo 2 > /proc/sys/net/ipv4/tcp_synack_retries; # stock is 5
echo "westwood" > /proc/sys/net/ipv4/tcp_congestion_control; # stock is cubic, wont change if westwood isnt avail

Edit: have been using this for the past 30 minutes. Seems like things like Facebook and XDA refresh slightly quicker vs stock, could be placebo though.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
I'm trying just the above and leaving everything else stock - will let you know how it goes.

No offense, but I see that the bug reports you listed are from kernel 2.6 and 14 - 17 years old - I don't think anyone has routers that old anymore. :p

Personally, I operate under the assumption that the Linux community and Google aren't so inept that there are dozens of tweaks that will help performance or battery life... else they would have been found and adjusted by now. As time goes on, a lot of the tweaks from the old days have been "fixed" or no longer do much since the devices are so much faster (as [MENTION=426561]Scott[/MENTION]) noted. If you try tweaking too many things at once, you really can't determine which ones are doing what. If you do stumble on one or two improvements but are simultaneously changing 10 more that hurt, you'll completely miss it, or worse yet actually reduce your performance overall. We found this many times over when osm0sis and the team were first testing many of the tweaks still in my script - and we realized we had to slow down and evaluate each tweak in series to make any real improvements, otherwise you're just analyzing noise. If we couldn't validate/verify a real improvement, we defaulted to stock settings for that parameter and moved on.

Bottom line: I really recommend trying one, or at most 2, things at a time, and getting actual data when possible to rule out confirmation bias / placebo effect. In absence of objective data, doing a blind subjective evaluation (have someone else change the parameters so you don't know in advance) is better than just changing things yourself because you'll always believe you're doing something constructive, even if you're not! The stuff in my current script (except LMK, which is more of a personal preference) has been through this level of rigor - at some point in the past each line was either data-proven to help performance or battery life without adversely affecting the other, or was nearly unanimously agreed to subjectively improve the device experience by a jury of multiple evaluators.

To reiterate, I REALLY appreciate the time and thought you're putting into this as it has been a while since this much effort has been put into researching and trying new things. I just think we need to be methodical about it in order to maximize the potential!

When I get home on Wifi tonight, I'll try to confirm if just changing tcp_ecn 0/1/2 increases data throughput.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
So, upon further review after isolating it as a variable, there is no statistical difference I can find by changing the tcp_ecn parameter from 1 to either 2 or 0.

However, I have decided that the LMK stuff in the script is going to the scrap heap of history (revert to stock)... after running stock for a few days I can tell no disadvantage vs. the settings I was using.

Moving on...
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
Sounds good. :) I might keep all my network settings and just remove the ecn and LMK from it. :)
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
New Version

Updated!

New version (94pks7)

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

Enjoy!
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] liver20:
Sorry... This module give me more perfomance and battery performance?

Enviado desde mi Pixel 2 XL mediante Tapatalk
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Most people report a little better performance and no change in battery life.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] liver20:
And how can see if mod is working in my device?

Enviado desde mi Pixel 2 XL mediante Tapatalk
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
It outputs a file to your internal storage. Open it with a text viewer and it says "successfully executed" if it ran.

If the file is not present or says it didn't execute, then it didn't run.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
Hey [MENTION=4793042]pkgnex[/MENTION] sorry to bother you, just throwing some ideas around with v7 script.

I'm a little OCD sometimes, and was wondering would it be beneficial setting this to 8MB as in 8192 instead of 7680?

echo 7680 > /proc/sys/vm/min_free_kbytes; # stock is 7548

Possibly be beneficial adding the mount command for /system too?

busybox mount -o remount,noatime,noauto_da_alloc,nodiratime,barrier=0,nobh /system;
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Hey, no worries or bother!

I'm a little OCD myself (although probably not quite to your level:)), which is why I rounded the min_free_kbytes up from the horrid stock number to at least a multiple of 512 ;). I'm certainly willing to give 8192 a shot, though, and will over the next few days.

I just went back through all the filesystem tweaks before releasing v7. When I tried adding mount to /system I was getting an error returned, so I left it out. Can you confirm or deny the same behaviour? It could be because I'm running busybox through magisk or something.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
Ahhh, didn't realise that it was multiples of 512. ?

I logged into my phone via ADB and ran the remount as root, without busybox at the start and it didn't error out however I did find https://xdaforums.com/showpost.php?p=75195480&postcount=16 which shows that /system isn't in fstab but this script has 100sec delay, so it should see /system eventually.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
Cool - thx.

I'll take another look at the mount fstab stuff tomorrow.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
So every time I try to do anything with mount... /system thorugh a script or terminal emulator, I get the following:

"mount: mounting tmpfs on /system failed: Invalid argument"

This even after the phone has been booted up for hours.

If you can figure out a different way to accomplish it, let me know.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
New File Location with Magisk 16.3+

Public Service Announcement:

Magisk 16.3 no longer creates and symlinks to the /magisk/.core/service.d location at startup.

Therefore, for this script to run, it must now be placed in /sbin/.core/img/.core/service.d.

This "new" location is actually the "real" late service startup location from Magisk 14.5 (i believe) onward, so in any case it is back-ward compatible with all recent stable and beta Magisk builds.

I will update the file by this weekend to reflect this new location in the header information (and maybe update one or two tweaks), but the current version works fine in the interim.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
New Version

Updated!

New version (94pks8)

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

Enjoy!
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] liver20:
Thanks for your work

Enviado desde mi Pixel 2 XL mediante Tapatalk
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
My pleasure.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
I already had the script in /magisk/.core/service.d however after flashing 16.3, it changed to /sbin/.core/img/.core/service.d and the script was still in there. :)

I see you added the remount for /system - guessing since it starts so late now, the script actually works to remount. :)

Will grab v8 and check it out. :)

Is there any benefit to lowering /proc/sys/vm/min_free_kbytes from stock?

I can see the vfs_cache_pressure has been lowered, should save some cpu cycles too. :)

Edit: I have found a couple more things for the filesystem that *may* help out

Add:

Setting it at less than 100 means that you will never use all your memory, and we know free ram is wasted ram.

echo 80 > /proc/sys/vm/overcommit_ratio; # stock is 50

Number of pages which are written to swap in a single attempt. The swap I/O size is 2^n (0-8). Setting it to zero means "1 page", setting it to 1 means "2 pages", setting it to 2 means "4 pages". I'm unsure how this will affect anything as we have swap disabled, but may be beneficial to set to "1".

echo 1 > /proc/sys/vm/page-cluster; # stock is 0

Edit:

Maybe increase this to say 50? This defines the memory cache filling threshold before background app data is written to internal memory (default 5%). It needs to be less than dirty_ratio (which it currently will be at 50).

echo 2 > /proc/sys/vm/dirty_background_ratio; # stock is 5

I've added / modified the values to the script anyway on my device. :) Just thought I would see what you think
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
Thanks for the explanations, it does make sense to keep d_b_r lower then.

Interesting about the sysctl info too, was a good read. I'll keep on reading and see if there's any other little bits that may help.

[MENTION=4793042]pkgnex[/MENTION] I found this write up on d_b_r and d_r - https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/ it's interesting to see the differences on this.

After looking at your v8 script of:

echo 2 > /proc/sys/vm/dirty_background_ratio; # stock is 5
echo 70 > /proc/sys/vm/dirty_ratio; # stock is 20, must be higher than dirty_background_ratio

Do you think it would be beneficial to change it to say:

echo 10 > /proc/sys/vm/dirty_background_ratio; # stock is 5
echo 60 > /proc/sys/vm/dirty_ratio; # stock is 20, must be higher than dirty_background_ratio
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
I've read that same article before - nice find! My philosophy is in line with the author's "both ways" method.

I imagine 10 / 60 would be fine, but I've honestly not noticed huge differences either way - I've used 30 / 70 in the past without any problems, but that was also on a device with only 25% of the RAM we have now. As Scott said, I'm not sure there's really much improvement to chase with these, but we certainly don't want to make things worse.

Why don't you try higher values like 10 / 60 and let me know what you find - better, worse, or indifferent? If there really isn't any difference either way, maybe I'll just revert to stock settings.
[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] Juzman:
I've been running 10/60 since I found the article and haven't really noticed any degradation in performance yet. Not sure if there is an improvement either. Haha.