[Google Pixel 2 XL ROMs, Kernels, Recoveries, & Oth] pkgnex:
I'm not sure why the /system mount started working - the script actually starts running

earlier

now... believe it or not, I think it had to do with moving it from the sym-linked /magisk location into /sbin as it started working as soon as I did that. :confused:

There might be some benefit from lowering min_free_kbytes, but like all things it would minor. In theory, this makes it so we're reserving less RAM in each memory node as overhead, so usable RAM should increase very marginally. I checked it, and it does seem to free a little (5 - 20 MB) RAM, but it's hard to tell for sure. You don't want to lower it too much, though, because if the system doesn't have enough memory reserved, it could just panic and kill stuff needlessly when you are trying to do anything that requires new memory allocation. I've seen suggestions on tuning this parameter all over the map, from reducing it slightly to increasing it hugely, but the latter was mostly for high RAM server-type applications on linux, and I've found that when this is the case, it very often works better to do the exact opposite on an android phone (since servers need max throughput and don't care as much about latency during interaction whereas our mobile devices don't benefit much from throughput increases but suffer greatly from latency increases).

Per the sysctl documentation, changing the overcommit_ratio doesn't do anything unless you change overcommit_memory to 2 (which is not a good idea - trust me on this one!). I checked this to make sure, and yep, increasing or decreasing it did not change available RAM whatsoever.

I see linux default page_cluster is 3 (8 pages) and on Android it's 0 (1 page). The sysctl documentation warns against possible latency increases by increasing this value, which is probably why Android minimizes it (latency trumps pretty much everything on touch devices in terms of user experience, so minimizing it is key to perceived performance). As you also said, since my script turns off swap, this shouldn't do anything either way in this script.

I don't believe raising dirty_background_ratio is a good idea. I've seen this recommendation before, too, but it is either old advice for devices with very low RAM, or for server-type linux applications. Even Linus Torvalds (invented linux) said d_b_r and d_r of 5 and 10 respectively was marginal or too high 11 years ago when machines have a fraction of the RAM they do now! Think about this: If you raise it to 50, the system will (in theory) wait until you have 50% of your total memory (2 GB!) used up and dirty before it starts writing anything to disk in the background! I'm guessing that if this ever happened, you had might as well just set your device down and wait 10 minutes for it to start working well again because it will be a laggy mess once that huge slug of data starts writing in the background. In practice, this doesn't happen because the dirty_expire and dirty_writeback parameters make the writeouts occur way before you ever hit 50% of memory usage, but since I increased those timers to reduce pdflush wakeups, I would rather lower d_b_r from stock than raise it and risk latency problems. What I believe we really want is for the system to start writing out little bits of dirty data in the background

sooner

, so it doesn't bring the entire system to a crawl when the writeouts get too large! Setting dirty_ratio (not background) higher is OK, though, because this represents the limit at which the system literally brings the data writing to the forefront and stops every other operation from occurring entirely until the write is complete... and we don't want that to happen unless absolutely necessary (i.e. if the system is about to collapse anyway).

Just my thoughts... since you asked. ;) I'm certainly not an expert on any of this, but I have played with tuning most of these parameters (setting both lower and higher) for several years and have learned some things. Please continue to let me know your thoughts and ideas.