[MOD] [A11-A12/A13, Magisk 23+] PK's Tuning Script v16/v17 [2022-05-26]

Search This thread

Zerosbar88

Member
Jun 16, 2022
17
1
Jalisco, México
Good day, I have some questions, I hope you can help me please:
1. I'm on the Lineage OS rom, can I install the script here?
2. When I update the rom will I lose the script or does it stay?
Thanks.
 

pkgnex

Senior Member
Aug 13, 2012
1,011
1,167
Michigan
Good day, I have some questions, I hope you can help me please:
1. I'm on the Lineage OS rom, can I install the script here?
2. When I update the rom will I lose the script or does it stay?
Thanks.
1. I believe you can install the script on any Pixel-4/XL ROM without issue.
2a. Whether the script stays is dependent on whether data is wiped or not during the update. I would guess it will usually stay in a LOS update, but a data wipe or factory reset will remove it.
2b. Even if the script is lost during an update, you can always put it back in the service.d folder and reboot.
 

Hailrake

Member
Jun 25, 2022
6
1
Google Pixel 4 XL
with any kernel, any scenario 16 or 17. always the same result. what to do? android 13
Screenshot_20220701-232846.png
 

pkgnex

Senior Member
Aug 13, 2012
1,011
1,167
Michigan
with any kernel, any scenario 16 or 17. always the same result. what to do? android 13
View attachment 5650375
You should use v17 on Android 13.

Please confirm your device is a Pixel 4 or Pixel 4-XL. If so, do your Magisk logs show it ran under "running service.d scripts"?

If the script file is in the service.d folder but isn't running, my best guess would be that you didn't open the permissions on the file before rebooting.
 

Hailrake

Member
Jun 25, 2022
6
1
Google Pixel 4 XL
Вы должны использовать v17 на Android 13.

Подтвердите, что ваше устройство — Pixel 4 или Pixel 4-XL. Если да, то показывают ли ваши журналы Magisk, что он работал под «запуском сценариев service.d»?

Если файл скрипта находится в папке service.d, но не запущен, скорее всего, вы не открыли права доступа к файлу перед перезагрузкой.
Yes, my device pixel 4 xl
Screenshot_20220707-135106.png
 

pkgnex

Senior Member
Aug 13, 2012
1,011
1,167
Michigan
So it appears to be running, but the output file isn't getting written - that may be an LOS thing, I don't know.

Can you use a kernal app (EX or Franco) and see what the Min GPU frequency is, ZRAM size is, and what the dirty_ratio / dirty_background_ratio's are? If they are 345 MHz, 3072 MB, and 10 / 2, respectively, then the script is running fine and just not writing the confirmation file at the end.
 

Hailrake

Member
Jun 25, 2022
6
1
Google Pixel 4 XL
Таким образом, кажется, что он работает, но выходной файл не записывается - это может быть проблема LOS, я не знаю.

Можете ли вы использовать приложение ядра (EX или Franco) и посмотреть, какова минимальная частота графического процессора, размер ZRAM и каковы значения dirty_ratio / dirty_background_ratio? Если они 345 МГц, 3072 МБ и 10/2 соответственно, то скрипт работает нормально и просто не пишет файл подтверждения в конце.
Yes, it really works, thanks a lot for your help
 

Attachments

  • Screenshot_20220723-185228.png
    Screenshot_20220723-185228.png
    149.5 KB · Views: 20
  • Like
Reactions: pkgnex

Top Liked Posts

  • There are no posts matching your filters.
  • 1
    Таким образом, кажется, что он работает, но выходной файл не записывается - это может быть проблема LOS, я не знаю.

    Можете ли вы использовать приложение ядра (EX или Franco) и посмотреть, какова минимальная частота графического процессора, размер ZRAM и каковы значения dirty_ratio / dirty_background_ratio? Если они 345 МГц, 3072 МБ и 10/2 соответственно, то скрипт работает нормально и просто не пишет файл подтверждения в конце.
    Yes, it really works, thanks a lot for your help
    1
    confirmed work on flame a13 beta 4.1, using kirisakura+this tweak, super smooth and average battrey, thanks
  • 31
    A11 & A11 - use v16
    A13 - use v16

    Hey Coral / Flame Gang!

    First off, I'm glad to be here. I just came from Pixel 2 XL after my phone died from hardware issues and I needed to upgrade!

    Anyway, here's a script that I put together for my own use, but still develop occasionally; tuned especially for our Coral / Flame devices.

    Enjoy!

    The Back-Story:
    I helped some good guys out with developing the awesome Franco.Kernel tuning parameters "back in the day" (Franco's Dev Team - you can look us up, the great osm0sis still hosts the original file set - but they won't even run on Android Pie or later). What is still applicable to Android 12 is in this file; trimmed and consolidated into a single script, along with some other goodies I've come across since. ;)

    Philosophy:
    - I don't write untested BS or questionable crap in my scripts. If a given tweak doesn't show an objective improvement in benchmarks or battery life or a subjective improvement in performance that can be turned on or off by running or not running the script in a blind test - it doesn't get added.
    - If I do not believe a given tweak is safe to run on everyone's daily driver device, I also won't include it my script, regardless of the benefit.
    - This script is biased toward increasing performance - but it takes advantage of battery saving opportunities that don't affect performance.

    Notes:
    - This script is lean and mean, but it's not rocket science.
    - I didn't invent anything here. Feel free to use it (or not), distribute, alter, whatever; to your satisfaction, giving credit for redistribution only to "Franco's Dev Team", and maybe me if you're feeling generous.
    - I have verified it works well on my personal Pixel 4 XL, and is compatible with all Android versions, Kernels, and Magisk versions applicable to the device.
    - It won't make your phone run any worse, and it should make it feel a bit "snappier", but YMMV.
    - Most benchmark scores improve marginally (1% - 4%) on my device with stock or EX kernel. Again, YMMV.
    - I do not plan to do heavy maintenance on this, but I will keep it up to date so it at least safely runs on the Pixel 4 / 4 XL as long as I own one. I will post updates with a minimal change log (it's a script, you can read it!). If I stumble across something that helps the community, I'll share it!

    Disclaimer:
    I can't see how this could possibly cause irreparable harm to any Android device on which it is run.
    However, I suppose untested configurations may (rarely) have slow-downs, reboots, or other effects.
    REGARDLESS, it is offered as-is with no warranty, and you choose to run this at your own risk.
    If you do encounter issues, let me know and stop using the script. I may ask you for further help with debugging.

    Requirements:
    Root
    BusyBox installation (I recommend the Magisk module by osm0sis)
    Knowledge of how to execute a linux script and/or where to place it and allow permissions to run on boot

    Usage:
    Download the linked file to your device
    Copy it to /data/adb/service.d
    Ensure permissions are correct (0755)
    Reboot and wait a three minutes

    NOTE: The script will generate a text file called "pksp4_script_result" in the base of your "external storage" directory (/storage/emulated/0). This file will state either "Success!" or "Failure..." indicating if the script completed at the last execution attempt (it will over-write each time the script is run - check the date/time stamp on the file properties) .

    Credits:
    Franco's Dev Team, esp. osm0sis
    Others as noted in the script file header


    9
    New Version - V3

    V3 available in OP, change log in 2nd post.

    Slightly better storage benchmark with Deadline and old Franco Dev Team tunables... probably not noticeable, but faster is faster! :D
    8
    New Version - V2

    A little Sunday night treat!

    V2 available in OP, change log in 2nd post.

    Better battery life as I tune this in for Pixel 4/XL...
    7
    I tried so hard to follow along with you guys crazy tech talk so if you don't mind dumbing all this down to users like me. I'm not a noob to Android but I know nothing about coding and building kernels etc. So my question is that is this mod still safe to use?

    It is "safe" to use - your phone isn't going to overheat, blow-up, stop working, or anything like that!

    Freak07 just pointed out that some things may not be optimized for Pixel 4/XL and the latest kernel we are running - which is understandable since I was using my script from a 2.5-year-old phone as a starting point for development.

    Bottom line... if you're already running a version of my script, you don't need to remove it and reboot your phone, BUT if you haven't started using it yet you might as well wait for V4. I will probably release V4 tomorrow, but in no case later than Friday.
    7
    Hey Freak07,

    Thanks for stopping by and providing thoughts / dropping some knowledge on me! I truly appreciate the discussion.

    I've read the twitter convo you linked, and will do more research on this topic as well - I'm always learning! That said, I'm still not yet sold on CFQ. Here's why:

    I'm not sure how "heavy workloads" were defined in the discussion, but using a reputable storage benchmark that reads 32MB files and writes 2MB ones (both sequentially and randomly), CFQ under-performs Noop in throughput. It always has. Those seem like reasonable phone-sized workloads to me, not the server-size ones I suspect may have been used in testing. Deadline, with the parameters adjusted as I have where the timeouts are cut in half and the batching and write starvation is reduced from the stock Linux setup performs better still. Granted, the differences are very minor, and it's playing at the margins at best; CFQ just has so much more over-head for a non-rotational device. I don't think choosing a different scheduler than CFQ is really undoing much optimization as you imply - and I certainly don't feel that subjectively on any device I've ever used my script on.

    Taking your other questions:

    ZRAM is still active with my script - and even with swappiness set at 5, it is still used substantially. Out of curiosity, have you tried running my script on Taimen or Coral to see how it changes behavior (if at all)? To me, it seems to just favor using physical RAM for immediate / recent tasks - ZRAM still fills up with background stuff. FWIW, I used to try turning ZRAM off, and that worked OK pre-Pixel (Nexus 6, 5, Galay Nexus), but you're right that Pixels seem to need it, so I have abandoned that effort. I reserve the possibility that I may be wrong about the effect of lowering swappiness, but I have not seen any negative effects so far, and it seems to work well with my workloads.

    I agree with you on wakelocks. The three wakelocks I chose to block are (or were), in fact, blocked by default on other kernels I have used (EX, Boype, and Franco, I believe - but not on this device, and perhaps not all of them on any one kernel except Flar2's on Taimen). I have never lost a notification due to any of these (or even a slightly expanded set like xFirefly93 uses) but I may walk one or two of them back with further testing.

    I also agree with you on the foreground schedtune boost - setting it to 5 does exactly what you said, it biases foreground apps to favoring bigger cores, increasing drain when the phone is idle and the screen is on. The benefit I'm shooting for and seem to have realized is a slightly faster response when switching to other apps in recents. The battery effect was minimal on Taimen, but I'm new to Flame/Coral, so we'll see! It may also be the case that app switching on Coral doesn't benefit from this like it seemed to on Taimen, again, I'm new to Coral and just trying things out that helped in the distant past or on my last device.

    Thanks again for the advice.

    :highfive:

    Good morning :)

    thanks for you open-minded answer. I try to give a few more details here.

    I'm not sure how "heavy workloads" were defined in the discussion, but using a reputable storage benchmark that reads 32MB files and writes 2MB ones (both sequentially and randomly), CFQ under-performs Noop in throughput. It always has. Those seem like reasonable phone-sized workloads to me, not the server-size ones I suspect may have been used in testing. Deadline, with the parameters adjusted as I have where the timeouts are cut in half and the batching and write starvation is reduced from the stock Linux setup performs better still. Granted, the differences are very minor, and it's playing at the margins at best; CFQ just has so much more over-head for a non-rotational device.

    I don´t think you should conclude that from the results of one artificial benchmark. That´s basically the same trap the google developer fell in, when he changed to deadline in the dev-preview.

    I don't think choosing a different scheduler than CFQ is really undoing much optimization as you imply - and I certainly don't feel that subjectively on any device I've ever used my script on.

    Isn´t thinking and feeling maybe the wrong tool to approach this topic? Why not looking at the code or the mechanisms google put into play?
    You´re wrong by thinking you just switched to another IO-Scheduler and didn´t undo other optimizations. You probably never triggered any workload with your personal usage or testing, where you felt that the optimizations you removed are gone.

    Google introduced the blkio cgroup during the preview for Android 10. That´s dependant on CONFIG_CFQ_GROUP_IOSCHED=y.
    Line 83 and following:
    https://android.googlesource.com/pl...fs/tags/android-10.0.0_r36/rootdir/init.rc#83
    See the commit here as well:
    https://android.googlesource.com/platform/system/core/+/2b3bf84373665e10d96c6b1680e5e53039505325

    Quite a bit of work was done on this topic over a few months to get it working correctly, if you follow the development.

    After booting successfully, there are specific values set for Pixel 4 devices.
    https://android.googlesource.com/de.../tags/android-10.0.0_r36/init.hardware.rc#590

    They are intended to help with various background work. On the Pixel 4 we have more of those than other devices such as soli, face recognition, uploading photos to cloud and others.

    ZRAM is still active with my script - and even with swappiness set at 5, it is still used substantially. Out of curiosity, have you tried running my script on Taimen or Coral to see how it changes behavior (if at all)? To me, it seems to just favor using physical RAM for immediate / recent tasks - ZRAM still fills up with background stuff. FWIW, I used to try turning ZRAM off, and that worked OK pre-Pixel (Nexus 6, 5, Galay Nexus), but you're right that Pixels seem to need it, so I have abandoned that effort. I reserve the possibility that I may be wrong about the effect of lowering swappiness, but I have not seen any negative effects so far, and it seems to work well with my workloads.

    You´re mistaken about this as well, and I saw that you left ZRAM enabled, that´s why I was talking about swappiness. I didn´t look at your Pixel 2 script until now. The Pixel 2 and Pixel 4 are not comparable in this regard. The Pixel 2 still uses the kernel-low-memory killer, because there´s no backport for the kernel-backend on 4.4 devices (only for 4.9, so Pixel 3 and upwards), that´s required for the userspace low memory killer in conjunction with PSI.
    But if you translate your settings or findings from the Pixel 2 to the Pixel 4 and compare both devices with regards to memory management, that´s just wrong.

    Google increased ZRAM size and changed swappiness to 100 on the Pixel 2, to counter the fact that 4GB RAM just isn´t enough to (semi) reliably keep apps in memory alongside Android 10, combined with the sad development that most popular (social media) apps just start to require more and more RAM over the last 2 years.
    https://android.googlesource.com/de...6f37008f6cd3ecf4724ed1994aaed2f8eef1fd9^!/#F0

    The userspace low memory killer, here´s some documentation works best with swappiness being set to 100 (pixel 4 default) or higher (that´s not in mainline, but you can change it up to 200 in my kernel if you want to (various other OEMs allows this, though 100 is default). Result is that swapping memory and dropping the cache have the same priority when set to 100. When swappiness is set to 5, it will strongly favor dropping the cache and almost never swap memory. The reason why you still see your ZRAM filling up slowly is the userspace lmkd being designed to do exactly this, even though you actively hinder it doing its job.

    Observing that disabling ZRAM on Pixel devices introduces negative effects was the first step :) Now try to understand how favoring swapping memory instead of dropping the cache works with the userspace lmkd!

    I also agree with you on the foreground schedtune boost - setting it to 5 does exactly what you said, it biases foreground apps to favoring bigger cores, increasing drain when the phone is idle and the screen is on. The benefit I'm shooting for and seem to have realized is a slightly faster response when switching to other apps in recents. The battery effect was minimal on Taimen, but I'm new to Flame/Coral, so we'll see! It may also be the case that app switching on Coral doesn't benefit from this like it seemed to on Taimen, again, I'm new to Coral and just trying things out that helped in the distant past or on my last device.

    You didn´t understand were I was coming from. When apps are opening on the Pixel 4, Energy-Aware-Scheduling gets disabled by the powerhal for 5 seconds. There won´t be a difference if foreground schedtune-boost is set to 5 during that time, because everything will be boosted to max (ignoring EAS) during these 5 seconds.
    Like I explained in my last post, you will only bias foreground tasks to the big cluster when the phone is without an interaction hint and there´s absolutely no need to bias towards big cores. (when being idle, watching videos, reading)


    Something I feel that needs to be clarified here as well. I´m not trying to make your work or your script look bad. In fact I´m bad at scripting myself so I admire everybody that is good at this. I´m just trying to provide a different perspective for tweaks that are counterproductive by just looking at the code and mechanisms in play here.
    Try to start looking into the actual mechanisms that are present on the Pixel 4 or in recent android develpment, instead of importing tweaks from other devices or the past that are out there on the internet.
    For example, I know there are a lot of tips or sites out there that advise people to turn of ZRAM or reduce swappiness, because it´s a waste of resources, but they just can´t be applied here. (they are years old as well, remember the times, were smartphones weren´t basically full blown mini computers in our pockets? :) )

    I REALLY appreciate this logic on potentially and unknowingly affecting others' devices... I will definitely consider un-blocking most, or all, wakelocks in my next release. The debugging ability for Dev's hits home, too. It's the reason I don't block any of the kernel-level logging stuff (except iostats ;)) that other script writers do.

    As I recall, there was really only one wakelock that was super-active anyway; I believe it was the qcom_rx_wakelock. I may just revert to blocking that one, or none at all, to make it safer for all users.

    qcom_rx_wakelock may look like worse than it actually is, but it´s not as impactful as it looks in apps like better battery stats. When I removed this wakelock completely in the wlan driver before compiling the kernel, guess what happened? I lost exactly the same amount of battery over a night on all four of my 4.14 devices. That´s why I said it´s a strange case.
    The wlan driver has more than enough ways to acquire a wakelock. If one wakelock is blocked most services/apps will just jump to using another. Or they will try to finish their job when a completely different wakelock is held. But that prolongs the time of other wakelocks. And in the end nothing will be won, except maybe a slight delay in notifications that you will never notice yourself.
    I know I start to repeat myself, but wakelocks should only be blocked in case of hardware or firmware incompatabilites, where the device fails to sleep completely.

    A very interesting read is the following one:
    https://arstechnica.com/gadgets/201...sts-tracks-and-improves-android-battery-life/