• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[MOD] [A11/A12, Magisk 23+] PK's Tuning Script v14 [2021-08-15]

Search This thread

pkgnex

Senior Member
Aug 13, 2012
970
1,148
Michigan
Hey everyone.

I pulled the trigger too soon on v11; battery life sucks!

I didn't notice it on my testing charge cycle, but have subsequently seen it.

If you, like me, think the slight performance boost is not worth the extra battery drain, please just revert to v10. I'll see if I can improve battery life on v12 soon.

That said, if you like v11, it's still fine to use it. It won't harm your phone in any way - other than reducing battery life. I just don't recommend v11 any longer.
 

Suavie103

Senior Member
Jun 15, 2014
149
26
Google Pixel C
Google Pixel 4 XL
Hey everyone.

I pulled the trigger too soon on v11; battery life sucks!

I didn't notice it on my testing charge cycle, but have subsequently seen it.

If you, like me, think the slight performance boost is not worth the extra battery drain, please just revert to v10. I'll see if I can improve battery life on v12 soon.

That said, if you like v11, it's still fine to use it. It won't harm your phone in any way - other than reducing battery life. I just don't recommend v11 any longer.
I've been using 11's script I haven't noticed any crazy battery drain but will let you know if I notice it. it runs smoothly on my p4 xl. thank you for you work
 

pkgnex

Senior Member
Aug 13, 2012
970
1,148
Michigan
I've been using 11's script I haven't noticed any crazy battery drain but will let you know if I notice it. it runs smoothly on my p4 xl. thank you for you work
Which kernel are you using? On EX, I noticed a substantial battery life reduction.

I am testing a V12 now that should put more load on the small cores through some schedutil up/down rate limit adjustments rather then just raising the minimum frequency. It seems to be at least as smooth as V10, and so far battery life seems at least as good as V10 as well. I'm going to test it for the rest of this week before releasing it, though!
 

Suavie103

Senior Member
Jun 15, 2014
149
26
Google Pixel C
Google Pixel 4 XL
Which kernel are you using? On EX, I noticed a substantial battery life reduction.

I am testing a V12 now that should put more load on the small cores through some schedutil up/down rate limit adjustments rather then just raising the minimum frequency. It seems to be at least as smooth as V10, and so far battery life seems at least as good as V10 as well. I'm going to test it for the rest of this week before releasing it, though!
well atm I'm using 4.14.222-Kirisakura-FLORAL7.1.1_NEXTGEN_CAF+ kernel

 

Attachments

  • Screenshot_20210316-020922.png
    Screenshot_20210316-020922.png
    337.5 KB · Views: 76
  • Like
Reactions: pkgnex

pkgnex

Senior Member
Aug 13, 2012
970
1,148
Michigan
New Version - V12

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

I believe I accomplished with V12 what I was trying to do with V11 - but without the negative battery life effects I noted on some kernels with V11.

Enjoy!
 

pkgnex

Senior Member
Aug 13, 2012
970
1,148
Michigan
This script works another devices?
Unfortunately, no; it is for Pixel 4 and Pixel 4-XL only at this time.

There are numerous aspects of the script that are tuned specifically for these devices, and they might cause issues on other devices.

I will add that I am now running the Android 12 Beta 1 and the script still runs and does it's job.
 

biTToe

Senior Member
Jul 11, 2012
77
19
Google Pixel 4 XL
Hi All,

So, I'm a bit of a n00b here as well but I would like to give this a try.

Am i correct in thinking that all I have to do is:
1) - Install BusyBox Magisk module by osm0sis
2) - d/l and extract the v12 .sh file
3) - copy it to /data/adb/service.d
4) - make permissions (0755)
5) - reboot, wait, profit?
 
Last edited:

pkgnex

Senior Member
Aug 13, 2012
970
1,148
Michigan
Hi All,

So, I'm a bit of a n00b here as well but I would like to give this a try.

Am i correct in thinking that all I have to do is:
1) - Install BusyBox Magisk module by osm0sis
2) - d/l and extract the v12 .sh file
3) - copy it to /data/adb/service.d
4) - make permissions (0755)
5) - reboot, wait, profit?
That's exactly right!

A log file will be written in your base storage directory that will confirm the script completed without any errors as well.
 
  • Like
Reactions: biTToe

pkgnex

Senior Member
Aug 13, 2012
970
1,148
Michigan
Any future updates coming pk. I just downloaded your script again. Been noticing crazy battery without it
Probably, but they will likely be minor.

Once the final Android 12 lands, I'll check to document anything that changed from A11 and give the script a good scrub. I'll also check to see if there is anything else out there from other Dev's that I can try out in the meantime.
 

pkgnex

Senior Member
Aug 13, 2012
970
1,148
Michigan
New Version - V14

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

I cast a wide net for any new tweaks "out there", and tested them all on A12 beta-4.

Most were useless, some actually caused freezes and stability issues, but a couple very minor ones tested OK (increase or no harm to benchmarks, stable for days even with hard use) and passed the logic test for either increasing throughput or reducing latency without harming battery life.

Although I initially resisted ZRAM years ago on Nexus 6 / Pixel 2, I have come to appreciate it with more time and learning. It helps a ton on Android devices as they age and the OS and apps take increasingly more memory. Why not have some more of a good thing ;).

Battery life seems unchanged to me on this build, with a little better performance - almost all of which is due to having more ZRAM.

Enjoy!
 
  • Like
Reactions: Darian71

Top Liked Posts

  • There are no posts matching your filters.
  • 1
    It's works with any custom ROM?
    Yes, it should work fine with any ROM.
  • 31
    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 later). What is still applicable to Android 10 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 / allow permissions to run on boot

    Usage:
    Download attachment to your device
    Un-zip the .sh file and copy it to /data/adb/service.d
    Ensure permissions are correct (0755)
    Reboot and wait 2 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/