Database Users

Quick question about kernels adversely affecting performance

This has happened to me maybe two or three times now, but I want to just focus on this time it's happening right now:
I installed the Villain kernel on 3.2.1 stock rooted rom, overclocked to 1.504GHz. Initially, the scrolling in landscape was as smooth as butter, but over the past few days it's become slightly choppy, and it's really bothering me, because I know I might have done something to mess this up. My question is, how do I fix this and make it so it has unbelieveably smooth scrolling again (just like when you pull it out of the box)? I think it's one of any number of things, really. It could be that I'm using cachemate, system panel pro, that I've used autostarts to stop a ton of applications from running at start up.
I just removed all of my game icons from the 2nd page (I only have two pages) and the scrolling didn't speed up, so it's not that.
Is there a a system app that relates to the scrolling that I might have disabled because it had a name that maybe I thought I could disable in autostarts?
Thanks for any help!

Stopping apps from autostart does not guarantee a performance improvement. This is not Windows and unused RAM is lost RAM. You're using more CPU power to kill constantly autostarting apps and services thus you're draining your battery faster. If a program resides in memory it still doesn't mean it does something. As an example, there were ROMs for HD2 that were developed to load completely in its RAM for superfast performance and yet battery life was still excellent. There might be apps that behave intrusive but that's not the majority of the cases. Try to isolate them with a tool like SystemPannel but first read its description @ the Market. Additionally try freezing with Titanium backup some of the apps you're definitely not using. Hope this helps.
p. s. Try switching from interactive to ondemand governor.

Ok, thanks very much for the info! I was talking to someone else about this earlier today and the made the same point as you.

Feature unlock: true multitasking

I chanced upon an app that could enable android users the ability to true multitask. Android is designed to cleverly close apps in the background that it deems unimportant. This feat is brought to fruitation through the assigning of minfree values. The higher the minfree value, the more seceptible the app is in being axed to conserve ram and computing space which inturn conserve battery.
With this in mind, theoretically, if we assign an app with a minfree value of 0, the apps will not be killed even when kingdom come. Pardon my attempt at humour if you aren't chuckling.
Now to the crux of this post. There is an inherent difficulty to assign minfree values and not everyone is a coder. Luckily there is an app on the market which let users assign minfree values and better yet, filters the apps into hidden apps and stuff. Simply download this free application from the market:
https://play.google.com/store/apps/...t=W251bGwsMSwxLDEsImNvbS5ycy5hdXRva2lsbGVyIl0.
Go to settings, enable advanced mode to get access to the first three values. One simply inputs "0,0,0,0,0,0". And voila, theoretically all hidden/background apps will not be killed and true multitasking is achieved.
A quick test of some programs that are designed to close after home button is pressed does not close now. Am happy to report that this trick does not close any background app. Only downside is user has to manually close the apps, which for me is more than ok. Hope this helps!!
[Update] I have changed all fields to 0. So technically what I am telling the GSIII is "do not have coffee breaks,toilet breaks and oh, "I own your sorry ass".
Am excited to report that N.O.V.A. 3 still continued running after opening maps with GPS, XDA, Maps, Internet browser. All of which are running.
[Update 2] Edited the values to "0,0,1,1,1,1" as a failsafe in case all rams have been used up. E.g. NOVA3 and MC3 concurrently running due to carelessness. Will report any drastic behaviour or successfully implementation without much drawbacks.
Sent from my GT-I9300 using xda premium

I'm interested to know how this affects battery life.

jiggytom said:
I'm interested to know how this affects battery life.
Click to expand...
Click to collapse
I am pretty sure this will suck the bejesus out of the battery. : ) Plus we aren't using the software for its intended use.

I did the same
Interesting to try...

sebarkh said:
I did the same
Interesting to try...
Click to expand...
Click to collapse
If in the event u have reached a satisfactory value do share! I was inspired by the "backgrounder" program of jailbroken IOS devices. It does the same thing except our way is different. From my Iphone days I have fetishes of true multi tasking. : )
Sent from my GT-I9300 using xda premium

The Linux/Android kernel WILL run OOM-Killer (Out-of-memory) with SIGKILL (removes the process from RAM and CPU without letting it any chance to save data or report) when the memory is full and it cannot continue operation otherwise.
Dalvik _should_ work around a full memory but by disabling this feature it won't so you might experience some data loss.
Consequently it is necessary to have a sufficiently large Swap-Partition on your SDcard to allow the kernel to get more memory whenever needed. It won't be fast when it hits the limit but at least it still works.

d4fseeker said:
The Linux/Android kernel WILL run OOM-Killer (Out-of-memory) with SIGKILL (removes the process from RAM and CPU without letting it any chance to save data or report) when the memory is full and it cannot continue operation otherwise.
Dalvik _should_ work around a full memory but by disabling this feature it won't so you might experience some data loss.
Consequently it is necessary to have a sufficiently large Swap-Partition on your SDcard to allow the kernel to get more memory whenever needed. It won't be fast when it hits the limit but at least it still works.
Click to expand...
Click to collapse
Well on top of that, the Minfree was programmed so that the CPU doesn't have to overwork and so it can run at lower frequencies.
Interesting app, but I'm going to leave the programming to the experts.

Plus prog is too much of a hassle for too little gains in this case. Hahaha.

I have to say that I miss the way the Palm Pre multitasked the best. I also like how pre handled contacts with multiple numbers/IM/google etc (something that ios6 is finally going to attempt to do). It would incorporate all of them into one message window using icons. If only some of that could be incorporated into Android!

[Q] Scrollling with pics = lag

Hi all,
I guess ever since getting the Nexus 7 when it came out, I've been trying to reduce lag. It has become as sort of project of mine. The last year, I have gone over lots of ROMs, kernels, tweaking tools, and tried lots of good (and very much bad) stuff.
So far, I've come quite far and I am quite happy with the way my Nexus 7 runs. The Nexus runs great in all other apps, really. Browsing is smooth and not comparable in any way to what I started out with. I have some Danish, poorly designed sites that are quite heavy, and I get no lag.
Apart from one thing - i get BAD lag when scrolling down a list which has images in it. I also get minor lag at other lists, but images makes it horrible. My two best examples are the play store (almost unusable) and gReader (slightly better with images off in lists, but hey, shouldn't have to be like that).
I've been googling loads and it seems very few people have the same problem? I've had this problem with all kinds of ROMs, kernels, tweaks, whatever really. I can have a crap setup with a million services running and a google now process gone haywire with cpu at 75 degrees celsius, yet the stutter is just the same in play store and greader (e.g.).
My current setup (but note, I've tried many with same result):
- Completely fresh install of recent CM10.1 nightly
- franco kernel (1.7GHz CPU, 700MHz GPU, 512Kb read-ahead, interactive, deadline, fsync off, gpu scaling off, wifi performance streaming)
- Almost all services disabled, including most of google's, meaning I have greenify running, a few under google services and android keyboard
- Sync is currently off
- Currents is not installed
- I've got fstrim installed and run that recently on all partitions
- I've got 9GB of 13-ish free at the moment
- Location sharing off
- Accessibility off
- No widgets, completely empty homescreen (I use Apex, not locked in memory)
I've been testing on a 100/100Mbit line fiber and 60/15Mbit LTE and identical experience.
I DO have Xposed installed atm, but after this fresh install (and many other similar times), I go straight to play store on a fresh install before installing anything. Same problem always there.
I had been using Trinity kernel for quite some time, at the time I adjusted read-ahead a lot, but in this situation a standard read-ahead actually means less lag for me. I guess it means more, small lags, actually, less noticeable.
I've been testing Seeder and similar apps recently, but get no particular difference with this problem.
When using the older version of Google Play, it is much more smooth, yet in the lists with apps it still stutters. Like 2-3 stutters a second, at times it hangs for a whole second, when scrolling down. It stutters each time and image is placed.
My experience: It seems the act of scrolling AND loading images doesn't work well in parallel.
I really hope someone can help me understand the problem, or, if so lucky, help me eradicate (or at least) reduce it.

Mkay, so it seems I am in a situation, where lagfix etc. doesn't alleviate the problem with very low random write speeds. I have done Forever Gone and various other things, but it just doesn't help. So, after googling a lot again, with inconclusive results:
What the feck is the conclusion on those low read speeds? I have plenty of space free...

delanvital said:
the play store (almost unusable)
Click to expand...
Click to collapse
The Play Store has always stuttered horribly when scrolling, as does Play Music. From my own observations, this is an issue with the implementation of rendering in these applications, rather than a lack of system performance. It is not isolated to the Nexus 7 either; it occurs within these applications on every Android device.
When you load the Play Store (or Play Music with album art) and begin to scroll, images are loaded when they come into view and unloaded once you move past them. I would surmise that the behaviour is intended to conserve RAM on less capable devices, however the consequence appears to be that this constant loading and unloading of images while scrolling results in stuttering. I have tested this hypothesis by comparing image-based applications (such as HTC Music) which do not implement the aforementioned function against those that do. The result is always that the former are completely smooth, while latter stutter incessantly.
Now that most new Android devices are shipping with 2GB of RAM, I do hope that Google will either remove this function or disable it on current devices (based on the brand/model the device identifies as).

Your tips for speeding up the phone?

Using an A2017U B29 stock rooted. I find the phone to be generally laggy, especially in opening apps or switching apps, but even in things like SwiftKey appearing… My OnePlus One felt faster. And also (separate issue, I understand) double-tap to wake is slow, as is screen-on in general.
Please share your tips for speeding up the phone. If you can include links to tutorials or explanation threads where relevant, even better!
Thanks :good:

That's sorta unanswerable but my first cheap tip is to disable window and menu animations. I imagine some manufacturers tweak the timings so you don't feel the lag- I mean... animations are intentional lag, right?
Just go into developer settings near the bottom and turn them to whatever the next to lowest setting is. Personally I just disable the 3 animation settings because they're dumb. A window fade-in/out effect is telling your computer to do a math equation each time you switch a window. I'd rather the window simply open.
The same goes for 3d and transparency.. Unnecessary math. Even Microsoft got rid of the Windows Vista orb start button in Windows 7 because it shaves a few cpu cycles off to render a square versus a circle.

get fstrimm from the playstore

Thanks! I had turned off some of the animations already but turned off the other two now as well. Didn't see a big difference. Not sure how to turn off 3d and transparency (and wouldn't that affect how apps look?).
Moved my photos and videos to the SD card… that helped, too.

[comment moved]

Thanks — I did. Not sure yet if it made a difference... Moved my photos and videos to the SD card… that also helped.

Upgrade to the ZTE Axon Dmix7 custom ROM. You can dirty flash it and continue using your software since it is just an optimized Stock ROM. It is by far more agile than the Stock B29. It is fully reversible, since you can also dirty flash the stock B29 ROM again.
On top of that you can increase your user experience by more than 10% by reformatting your data partition to F2FS. This process is also reversible and very easy following the guide you can find in my signature.

I am using AKT kernel tweaks for SD820 since 3 days. My phones feels blazing fast now, and batterylife improved too. Check it out!
https://forum.xda-developers.com/oneplus-3/how-to/advanced-interactive-governor-tweaks-t3476589
(you need to be rooted and unlocked to use this)

How to disable/adjust the background task limit?

My background with android is long and rocky.
A long time ago in a galaxy far away, I had a Samsung Galaxy S, then a S2.
I can remember a Google Nexus phone in there somewhere.
Then at some point I switched over to Windows Mobile for many years.
A couple of hears ago I came back to android with a Samsung Galaxy S8+ and I hated it.
Recently I upgraded to a OnePlus 6T McLaren and here I am.
I had been expecting to see android happily use up 7, 8 or even 9GB of ram before the background task manager would begin to kill tasks.
Except that I seldom saw android use much more than 5GB of ram.
And worse, background tasks were being killed on a regular basis.
Widgets would stop working overnight, or even in just a few hours.
Spotify would close while a playing a playlist.
A quick search on XDA reveals that many users believe that Android will just use up as much ram as your phone has.
However, that is simply not true.
And so, I began my quest to have Android use as much ram as the phone could provide.
In my case, 10GB.
- I understand that there is an inherent trade-off between keeping background apps running and battery usage. I can live with extra battery usage in exchange for keeping my widgets running or Spotify running for an entire playlist.
- I realized very quickly that in order to achieve the results that I was looking for that the phone would have to be rooted. So rooting was one of the first things that I did.
Step 1.
I started with the basic stuff that a quick google search would provide;
- Settings -> Battery -> Battery Saver (off)
- Settings -> Battery -> Adaptive Battery (off)
- Settings -> Battery -> Battery Optimization -> widget app (don’t optimize)
- Settings -> Battery -> Battery Optimization -> Spotify (don’t optimize)
- Settings -> Battery -> Battery Optimization -> Advanced Optimization -> Deep Optimization (off)
- Settings -> Battery -> Battery Optimization -> Advanced Optimization -> Sleep standby optimization (off)
- Settings -> Apps -> Widget app -> Battery -> Background Restriction (app can use battery in background)
- Settings -> Apps -> Spotify -> Battery -> Background Restriction (app can use battery in background)
This helped but not enough to make the widgets or Spotify usable.
Step 2.
I supposed that my specific background tasks that I wanted to keep running were being killed because of the many other apps that were running in the background.
I searched for and found Tomatot DeBloater scripts for the Oneplus 6.
Excellent! Just what I was looking for.
I chose the Tomatot-Debloater-OOS-Light-2.3.zip and installed it.
This helped some more but not enough to make the widgets or Spotify usable.
Step 3.
I realised that there were still some apps running in the background that I didn’t use or want.
So I used Titanium Backup to freeze the following apps;
- Calendar
- Calendar Storage 9
- Contacts (O+)(I replaced with google contacts)
- Dashboard
- Drive
- Face Unlock
- Gboard
- Gmail
- Google
- Google partner setup 9
- Google play music 8
- McLaren AR
- Messaging (O+)(replaced with google messaging)
- OK google enrollment 9
- Oneplus system 1
- Youtube
Perfect! These apps were no longer competing for phone resources with the apps that I wanted to run.
This helped some more but not enough to make the widgets or Spotify usable.
This did make the phone feel faster and smoother.
The phone is much more responsive and fluid to my input.
This made me realize that the apps were being closed not due to a lack of phone resources, but a background task manager being aggressive.
Presumably for battery saving purposes.
I changed my focus to adjusting that background task manager.
Step 4.
Enable the recent screen ‘LOCK’ on the widget app and Spotify.
This didn’t do anything for me.
Everything that I’ve read on it says that it just stops the task from being killed when you click on kill all tasks.
The lock doesn’t lock the task from being killed by the background task manager.
Step 5.
Further google searching led me to believe that the OEM kernel was limiting background tasks.
I choose ElementalX-OP-3.09 and the EX Kernel Manager.
I had to read a lot of google university material to make any sense of the settings in here.
I’m not sure that I fully understand even now.
Eventually, I ended up with the following settings;
Memory
- Adaptive Low Memory Killer (disabled)
- dirty ratio (20)
- dirty background ratio (5)
- min free kbytes (12398)
- vfs cache pressure (100)
Memory -> Low Memory Killer
- apply on boot
- Foreground app (72mb)
- Visible apps (90mb)
- Secondary server (108mb)
- Hidden apps (200mb)
- Content Providers (587mb)
- Empty apps (783mb)
This helped a lot.
This almost made the phone usable to the state that I wanted.
But the widget and Spotify would still stop running overnight and by morning the apps would have to be reopened to get them to run again.
At least the apps would run most of the day without being killed.
Still not the behaviour that I expected from a phone with 10GB of ram.
Ram usage was still not going much over 5.5Gb even if I opened up many apps at once.
Can I ever get ram usage up to the 10Gb that I have?
Step 6.
The last thing that I tried yesterday afternoon was to increase the background task limit in the build.prop.
ro.vendor.qti.sys.fw.bservice_limit=5 (changed it to 60)
ro.vendor.qti.sys.fw.bservice_age=5000 (changed it to 10000)
Yes, I know that I am on PIE and there isn’t supposed to be any effect.
No, I don’t know yet if this had any effect.
I am hopeful.
The widget app didn’t close last night, but Spotify did.
I am getting closer!
This is the best that I could do on my own without asking for help.
So here I am posting my question and asking for help.
How do I get the apps that I want to run to not be killed by the background task manager?
OR
How do I get the phone to use the 10GB of ram?
I feel that I am missing something.
With any luck, one of you smarter persons will be able to point it out to me.
As an aside from all of these changes the phone feels very smooth and fluid.
Except for apps closing that I don’t want to, this phone is a great experience and a pleasure to use.
Apps that I want to run are staying open much longer then before I started.
It’s now just an overnight issue.
And getting the phone to use over 6Gb of ram.
I would suggest that I am 90% happy with it now.
KERNAL: ElementalX-OP6-3.10
ROM: STOCK OOS 9.0.11
PHONE MODEL: 6013 O+6T McLaren

Tomorrow I may try making this change to the build.prop file;
ro.vendor.qti.sys.fw.bservice_enable=true to false
Don't know if it will help or not.

Wow dude, interesting read, i will sign up for notifications from this thread hoping you get your answer because i have the exact same problem but with my work app, throwing it all out of whack and making me a target to big fines (in the $1,000's) and potentially reducing my marketability!
The attached screenies are from before i realized that the app getting killed in the background is what causes the problem (I've left it in the foreground HOURS a few times and it works perfectly!)

UPDATE:
Good news!
I seem to have solved my issue.
Time will tell for sure though.
But this morning and all day today, Spotify and the widget app have been running without closing.
AND I have seen memory usage up to 6.8GB used.
Here are the further steps that I took;
- ro.vendor.qti.sys.fw.bservice_enable=true (changed it to false)
I didn't really notice much of a change.
But then I noticed that perhaps the limit of 60 tasks was not high enough.
I seem to have that many apps open and limiting to just 60 may be an issue.
- ro.vendor.qti.sys.fw.bservice_limit=60 (changed it to 120)
THIS!
This seemed to have worked for me.
All apps seem to be open and be staying open.
Today I got a message/warning from android telling me that the widget app is consuming the battery in excess but I ignored the warning and android did not close the app or stop the widget from running.
I will keep an eye on the phone for the next few days to confirm that this actually solved my issues.
My next step will be to see what effect if any this has had on my battery usage.
I am curious to see if it's all that bad...

geeksquad2 said:
UPDATE:
Good news!
I seem to have solved my issue.
Time will tell for sure though.
But this morning and all day today, Spotify and the widget app have been running without closing.
AND I have seen memory usage up to 6.8GB used.
Here are the further steps that I took;
- ro.vendor.qti.sys.fw.bservice_enable=true (changed it to false)
I didn't really notice much of a change.
But then I noticed that perhaps the limit of 60 tasks was not high enough.
I seem to have that many apps open and limiting to just 60 may be an issue.
- ro.vendor.qti.sys.fw.bservice_limit=60 (changed it to 120)
THIS!
This seemed to have worked for me.
All apps seem to be open and be staying open.
Today I got a message/warning from android telling me that the widget app is consuming the battery in excess but I ignored the warning and android did not close the app or stop the widget from running.
I will keep an eye on the phone for the next few days to confirm that this actually solved my issues.
My next step will be to see what effect if any this has had on my battery usage.
I am curious to see if it's all that bad...
Click to expand...
Click to collapse
Nice find, I checked my build.prop and found this. No wonder my apps are killed
Code:
#ifdef VENDOR_EDIT
#[email protected] modify for app memory
ro.vendor.qti.sys.fw.bservice_enable=true
ro.vendor.qti.sys.fw.bservice_limit=5
ro.vendor.qti.sys.fw.bservice_age=5000
#endif/*VENDOR_EDIT*/
EDIT: I see a lot of custom ROM's have "ro.vendor.qti.sys.fw.bg_apps_limit=60" to the build prop, I wonder if that going to make a difference

UPDATE:
I am a silly goose.
I broke a cardinal rule while troubleshooting.
I may have had a few too many wobbly pops and made two changes at a time, thus when change was affected, I was unable to determine properly which change caused the affect.
The rule is, "only make one change at a time when testing".
Yes, all of my apps stay open all the time.
I am getting the behaviour that I was looking for.
However it wasn't necessarily changing the build.prop bgservice_limit from 60 to 120 that did it.
Let me back up a bit.
Earlier I had suggested that locking an app to the recent screen didn't do anything for me, and that in my reading it only locks the app from being killed by you when you try to close it manually.
However in reading up on the oneplus framework-res.apk I found a reference to an oneplus whitelist of apps that will never be killed, and a reference to the recent screen app lock that suggests that oneplus will add a locked app to the whitelist and not kill it.
In the course of a single day, I had inadvertently edited the build.prop and locked the widget app to the recent screen thus breaking the one change at a time rule.
So the next morning and the following days when all apps were staying open I attributed it to changing the build.prop not realizing that it could also have been the app lock.
Last night I realized my mistake.
I unlocked the widget app from the recent screen and went to bed.
When I woke up this morning the widget app was not running for the first time in days.
Also the notifications that I was receiving about the widget app consuming excessive battery have stopped.
It would appear that I was wrong in my earlier observations regarding the app lock mechanism.
It appears to be very useful for keeping apps running all the time.
Did changing the build.prop have any affect on keeping apps open?
Maybe?
I have noticed that my battery life has gone for a complete ****.
I can barely get 24 hours out of the phone.
Worse is that it doesn't matter if the screen is on or not, battery usage remains the same.
i.e. with the screen off and the phone put down, battery life appears to be used at the same rate as when the phone is in use.
I had expected the battery life to be not as good, but I didn't expect it to go to for a **** that badly.
There must be a balance between aggressive app management and acceptable battery life.
The phone didn't display this behaviour until I changed ro.vendor.qti.sys.fw.bservice_enable=true to false.
I think that today I will change ro.vendor.qti.sys.fw.bservice_enable= back to true and observe the battery tomorrow.

kantjer said:
Nice find, I checked my build.prop and found this. No wonder my apps are killed
Code:
#ifdef VENDOR_EDIT
#[email protected] modify for app memory
ro.vendor.qti.sys.fw.bservice_enable=true
ro.vendor.qti.sys.fw.bservice_limit=5
ro.vendor.qti.sys.fw.bservice_age=5000
#endif/*VENDOR_EDIT*/
EDIT: I see a lot of custom ROM's have "ro.vendor.qti.sys.fw.bg_apps_limit=60" to the build prop, I wonder if that going to make a difference
Click to expand...
Click to collapse
I think that ro.vendor.qti.sys.fw.bservice_limit= and ro.vendor.qti.sys.fw.bg_apps_limit= are essentially the same thing, except for android versions.
ro.vendor.qti.sys.fw.bg_apps_limit= is for Android 7: Nougat and below.
ro.vendor.qti.sys.fw.bservice_limit= is for Android 8: Oreo and above.
Someone more knowledgeable than me should chime in here though.

Do you think any of this could have to do with the way the phone keeps disabling push in Gmail? (Every other day I need to set my O365 exchange in Gmail back to push because it automatically changes to the default of checking every 30 mins.)

Any conclusion?

Did you guys manage to solve this issue please by editing the build prop?

Latest smurf kernel rc14b seems to have solved the RAM management issue. I haven't had any apps closing in background since using it.

thank you for the thread!

What did you find in the end?
How did you set this ?
ro.vendor.qti.sys.fw.bservice_enable=true
ro.vendor.qti.sys.fw.bservice_limit=5
ro.vendor.qti.sys.fw.bservice_age=5000

So what's the verdict on the buildprop edits? Do they make a difference?
I notice that sometimes my on-going weather notification doesn't update, or gets killed off. I also have an app that controls rotation per app, and that also seems to stop doing it's thing after a while.

Just want to share. If you are rooted with Magisk, try appsystemizer module. System apps don't get killed by oneplus as aggressively. Tried it with accubattery and it works.

I am so glad I stumble across this, I just want to say, changing
ro.vendor.qti.sys.fw.bservice_limit=5 to 120
ro.vendor.qti.sys.fw.bservice_age=5000 to 10000
Keep apps in ram for much longer then original! For me the battery life is unaffected, might even be better.

scloss84 said:
I am so glad I stumble across this, I just want to say, changing
ro.vendor.qti.sys.fw.bservice_limit=5 to 120
ro.vendor.qti.sys.fw.bservice_age=5000 to 10000
Keep apps in ram for much longer then original! For me the battery life is unaffected, might even be better.
Click to expand...
Click to collapse
Also want to solve this issue.
On which OOS Version you are? (i am on 10.3.1)
Does this really work in newer OOS Versions?
I have read elsewhere that those settings dont work on newer versions, sadly, cant find the thread/source.
thx
pOpY

popy2006 said:
Also want to solve this issue.
On which OOS Version you are? (i am on 10.3.1)
Does this really work in newer OOS Versions?
I have read elsewhere that those settings dont work on newer versions, sadly, cant find the thread/source.
thx
pOpY
Click to expand...
Click to collapse
I'm actually Oneplus 6, OOS 9.0.9.
I also read that it doesn't work on Android 10 because magisk doesn't mount /system in Android 10, but there is a magisk module workaround that you can use. And hopefully magisk will update in the near future to fix that. Just google "Android 10 can't edit build.prop" and you'll find heaps of info.

This is what I have in my build.prop file and it seems to help. I have Oreo it works great on my phone I don't know about later versions of Oreo.
ro.vendor.qti.sys.fw.bservice_enable=true
ro.vendor.qti.sys.fw.bservice_age=5000
ro.vendor.qti.sys.fw.bservice_limit=5
ro.sys.fw.bg_apps_limit=64