We hate zram. This easy mod will disable it on the stock Moto G4 rom. In our experiences with disabling zram we've been able to notice performance gains on devices from 1-3gb of ram (Moto E 2015, Moto G 2014, Honor 5X, Huawei GX8).
8/13/16 Update: Now flashable via TWRP.
1. Have TWRP and MAKE A NANDROID BACKUP BEFORE YOU DO ANYTHING. I am not responsible if you break your phone. If you don't already know how to restore your device to the way it was when you bought it, do not do any of this.
2. Flash via TWRP:
Zram Off: https://www.androidfilehost.com/?fid=24588232905722629
To return to stock (I cannot promise this is exactly the same as the G4 Plus. If any G4 Plus users want to send me a hastebin of the /system/etc/init.qcom.zram.sh file to compare that would help).
Zram On: https://www.androidfilehost.com/?fid=24588232905722630
Old instructions if you prefer to do it manually:
1. Be rooted.
2. Have a stock nandroid backup.
3. Backup /system/etc/init.qcom.zram.sh to some safe place.
4. Unzip MotoG4_Zram_Disable
5. Using root file manager of your choice (I like Solid Explorer) copy init.qcom.zram.sh to /system/etc folder and overwrite the existing file.
This has been tested working on the XT1625 and likely works on the G4 Plus as well. If this works for you on a different variant, please leave a reply and I'll do my best to update this post.
Links:
Disable Zram: https://www.androidfilehost.com/?fid=24588232905722479
If for some unholy reason you'd like to turn it back on, follow the same process copying your backed up init.qcom.ram.sh file back to /system/etc.
Thanks to @EarlyMon for his edits that allow us to keep zram disabled without having to run terminal commands at every boot.
Wouldn't it be easier to use something like EX kernel manager. Thank you for your hard work though
khaoticking said:
Wouldn't it be easier to use something like EX kernel manager. Thank you for your hard work though
Click to expand...
Click to collapse
I did use kernel adiutor, but zram support has been removed. Can't speak to EX kernel manager. However, the one advantage is that it boots with it turned off. Either solution would work, but this should be faster and possibly one less app you have to install if you're OCD about how many apps you have on your phone.
Very true and ex kernel manager does support it still and @flar2 does great work keeping the app updated
Confirmed working on my 4gb ram g4 plus.
What is the purpose of ZRam feature?
Sent from my XT687 using xda premium
---------- Post added at 01:06 AM ---------- Previous post was at 01:04 AM ----------
If you gain performance without this, it sounds like foot of brake by the manufacturers, NOH?
Sent from my XT687 using xda premium
fix-this! said:
Confirmed working on my 4gb ram g4 plus.
Click to expand...
Click to collapse
Thanks for sharing your result!
Dethfull said:
What is the purpose of ZRam feature?
Click to expand...
Click to collapse
Zram is virtual ram to give low ram devices more available ram by using a partition on the nand. Essentially you have info moving from ram to the nand and in the background you have constant zipping and unzipping process running as this information is being moved around. We believe it leads to lag (ever need to reboot because the phone starts slowing down?) and crappy performance as well as additional, unnecessary wear and tear on your nand. Android manages ram just fine without zram. @EarlyMon could do a much better explanation, but this is the over simplified version as I understand it.
See this for a better explanation: http://forum.xda-developers.com/showpost.php?p=65156077&postcount=6
redbeard1083 said:
Zram is virtual ram to give low ram devices more available ram by using a partition on the nand. Essentially you have info moving from ram to the nand and in the background you have constant zipping and unzipping process running as this information is being moved around. We believe it leads to lag (ever need to reboot because the phone starts slowing down?) and crappy performance as well as additional, unnecessary wear and tear on your nand. Android manages ram just fine without zram. @EarlyMon could do a much better explanation, but this is the over simplified version as I understand it.
Click to expand...
Click to collapse
I was under the impression that it was virtually the opposite of your explanation...
Z ram uses a compressed "ram disk" for paging BEFORE hitting the nand memory... to not only help in speeds of retrieval but to keep nand write to a minimum (since solid state storage only has a finite amount of write cycles). The lag comes from having to "unzip" the info from the ram disk before use when switching between apps. (this takes some CPU power and obviously a bit of lag can be seen sometimes). However, zram is there to help by giving a use for unused ram when not in use as well as keeping unnecessary writes from hitting the nand.
If a app requires the memory currently in use by zram, the linux kernel will unload the data to the disk (or ssd / nand) and recall the info as a normal page file when needed to free up the ram when necessary.
Before and after, results on AnTuTu. Not a big difference, but I have to admit, the phone does seem to run smoother.
MadGoat said:
I was under the impression that it was virtually the opposite of your explanation...
Z ram uses a compressed "ram disk" for paging BEFORE hitting the nand memory... to not only help in speeds of retrieval but to keep nand write to a minimum (since solid state storage only has a finite amount of write cycles). The lag comes from having to "unzip" the info from the ram disk before use when switching between apps. (this takes some CPU power and obviously a bit of lag can be seen sometimes). However, zram is there to help by giving a use for unused ram when not in use as well as keeping unnecessary writes from hitting the nand.
If a app requires the memory currently in use by zram, the linux kernel will unload the data to the disk (or ssd / nand) and recall the info as a normal page file when needed to free up the ram when necessary.
Click to expand...
Click to collapse
Here's a better explanation of what we're doing. From the Honor 5X forum: http://forum.xda-developers.com/showpost.php?p=65156077&postcount=6
NexusFan9219 said:
Before and after, results on AnTuTu. Not a big difference, but I have to admit, the phone does seem to run smoother.
Click to expand...
Click to collapse
We've had some trouble nailing down significant performance gains on other devices using benchmarking tools, but yeah I would agree that the user experience is smoother.
MadGoat said:
I was under the impression that it was virtually the opposite of your explanation...
Z ram uses a compressed "ram disk" for paging BEFORE hitting the nand memory... to not only help in speeds of retrieval but to keep nand write to a minimum (since solid state storage only has a finite amount of write cycles). The lag comes from having to "unzip" the info from the ram disk before use when switching between apps. (this takes some CPU power and obviously a bit of lag can be seen sometimes). However, zram is there to help by giving a use for unused ram when not in use as well as keeping unnecessary writes from hitting the nand.
If a app requires the memory currently in use by zram, the linux kernel will unload the data to the disk (or ssd / nand) and recall the info as a normal page file when needed to free up the ram when necessary.
Click to expand...
Click to collapse
Hi.
You're correct about zram overall up to the point that it helps by giving use for unused ram.
Let's clarify for everyone's sake.
Swap is virtual memory strategy to augment available RAM.
It first appeared for most people on desktops using a portion of the hard drive to emulate RAM, and (simplified version) swapped the contents of RAM with the local storage set aside for that, back and forth as needed - to assist with better overall multitasking, and for that it worked a treat. (It actually first appeared on mainframes and then minicomputers for those with OCD.)
Android is a real-time Linux implementation and Linux has virtual memory strategies including swap as part of its mainframe heritage.
2010 saw the rise of the superphones with an astonishing 512 MB of RAM on board - with most Androids having far less - and then take away some for hardware functions, then the operating system, and what was left was yours for apps.
I've been using Android since 2009 and I don't remember who started it or when, but by the summer of 2010, adding swap to an Android by repartitioning the SD card and exploiting that the kernel already knew how to use it for swap if done right had become a darling mod.
Eventually phones got enough ram to outgrow it (and while popular with many, the mod was never universally accepted as the right thing to do) but manufacturers kept producing cheap phones without sufficient hardware resources (still do, sadly) and so the mod never actually died gracefully.
And let's stay in the real world - Android is a compact, real-time Linux - it's not a desktop Linux distribution and it was specifically designed for mobile use.
Enter the Dalvik virtual machine, the cornerstone that makes Android different from a desktop, and it's post-KitKat replacement, the Android Runtime.
Either way, let's call that the Android machine.
And what it does is provide the app environment with the job control and RAM management for apps within a closed system, above the kernel, and it does everything you need for shuffling apps around and optimizing your multitasking experience.
It doesn't need any help, all things being proper.
But things aren't always proper and starved phones continue to be made.
Enter Qualcomm.
They provided a shell script to add swap back on for phones choking with less than 1 GB of RAM on board in hardware.
It's in /system/etc/init.qcom.zram.sh on your new Moto and it's what I provided the patch for.
Initially, it tested to see if a phone had less than 1 GB RAM and do nothing if 1 GB or larger, otherwise, set up and launch zram.
And all zram is is a set aside in RAM that's used for swap through the magic of compression and decompression to try to get the appearance of more RAM.
This sounded so great on paper that this travesty has been adopted by flagships and the Nexus and Google has even codified it for manufacturers with what they consider to be appropriate guidelines for implementation.
Frankly, it's change for change's sake by developers who have no full grasp of the history of Android swap and live in a theoretical world without looking at what it really does to user performance in the face of a larger Android needing more RAM in the first place, on less than ideal mobile processors.
Android already does multitasking management without giving the processor a redundancy with compression and decompression lying to it about available RAM and it's highly optimized after years of ongoing refinement.
Zram is a moving target that fails often (Nexus 6P owners who don't get rid of it like to reboot their phones every few days to restore speed, something not needed by people who have taken the cure, thanks to entropy with zram processing) and manufacturers think that this lipstick will look even more red on the pig if they increase the compression ratio.
Stealing CPU resources that you need a lot more than you need RAM.
Go ahead and look in /system/etc/init.qcom.zram.sh on your Moto - please don't take my word for it.
Moto has followed in the new Chinese tradition of changing what that file does, ignoring that Qualcomm said in the comments, in plain English, to only do this for phones without enough RAM.
The Moto doesn't qualify and doesn't need it by design.
You can also see that all it does is call the toybox command to turn it off right after boot, at the end of initialization.
I left the original Moto contents in place because the OP asked late at night for some help when Kernel Adiutor took the turn-off feature away and I never got back to help with something that looked prettier. (And nothing bad on Kernel Adiutor, zram implementation and proliferation is getting to be a burden for maintenance, I don't blame them.)
Past the comments, Moto did not leave the original Qualcomm code in place.
The canonically correct no-swap fix for your phone would be to go in to the ramdisk in the boot image and remove where it gets turned on in the first place.
And then have to redo the mod every time Moto updates that.
Ain't nobody got time for that, and I don't own this phone, I'm helping friends solve this problem with the easy button.
My method leaves the zram declaration in place (you can see it in /proc/partitions) but it's harmlessly unused after the mod.
To learn more about the state of your memory and get some simple explanations without all the voodoo, check out "RAM Truth"
https://play.google.com/store/apps/details?id=sa.ramtruth
It doesn't spy on you, it has no ads or tricky revenue games, it's something that two of us provided as a labor of love for the Android community because after a lot of years, we were repeating the same answers to the same questions.
Knowledge is power ok.
And if you disagree with me about how zram sucks and needs to have a stake driven through its heart, flash the bit that restores your phone to the way it was when you got it and enjoy it in good health. About one in a thousand go that way and that's fine. No need for debate.
Android is all about choice.
Hope this clarifies, thanks for reading, sorry for typos, this was all just flow of consciousness without editing.
EarlyMon said:
Hi.
You're correct about zram overall up to the point that it helps by giving use for unused ram.
Let's clarify for everyone's sake.
Swap is virtual memory strategy to augment available RAM.
It first appeared for most people on desktops using a portion of the hard drive to emulate RAM, and (simplified version) swapped the contents of RAM with the local storage set aside for that, back and forth as needed - to assist with better overall multitasking, and for that it worked a treat. (It actually first appeared on mainframes and then minicomputers for those with OCD.)
Android is a real-time Linux implementation and Linux has virtual memory strategies including swap as part of its mainframe heritage.
2010 saw the rise of the superphones with an astonishing 512 MB of RAM on board - with most Androids having far less - and then take away some for hardware functions, then the operating system, and what was left was yours for apps.
I've been using Android since 2009 and I don't remember who started it or when, but by the summer of 2010, adding swap to an Android by repartitioning the SD card and exploiting that the kernel already knew how to use it for swap if done right had become a darling mod.
Eventually phones got enough ram to outgrow it (and while popular with many, the mod was never universally accepted as the right thing to do) but manufacturers kept producing cheap phones without sufficient hardware resources (still do, sadly) and so the mod never actually died gracefully.
And let's stay in the real world - Android is a compact, real-time Linux - it's not a desktop Linux distribution and it was specifically designed for mobile use.
Enter the Dalvik virtual machine, the cornerstone that makes Android different from a desktop, and it's post-KitKat replacement, the Android Runtime.
Either way, let's call that the Android machine.
And what it does is provide the app environment with the job control and RAM management for apps within a closed system, above the kernel, and it does everything you need for shuffling apps around and optimizing your multitasking experience.
It doesn't need any help, all things being proper.
But things aren't always proper and starved phones continue to be made.
Enter Qualcomm.
They provided a shell script to add swap back on for phones choking with less than 1 GB of RAM on board in hardware.
It's in /system/etc/init.qcom.zram.sh on your new Moto and it's what I provided the patch for.
Initially, it tested to see if a phone had less than 1 GB RAM and do nothing if 1 GB or larger, otherwise, set up and launch zram.
And all zram is is a set aside in RAM that's used for swap through the magic of compression and decompression to try to get the appearance of more RAM.
This sounded so great on paper that this travesty has been adopted by flagships and the Nexus and Google has even codified it for manufacturers with what they consider to be appropriate guidelines for implementation.
Frankly, it's change for change's sake by developers who have no full grasp of the history of Android swap and live in a theoretical world without looking at what it really does to user performance in the face of a larger Android needing more RAM in the first place, on less than ideal mobile processors.
Android already does multitasking management without giving the processor a redundancy with compression and decompression lying to it about available RAM and it's highly optimized after years of ongoing refinement.
Zram is a moving target that fails often (Nexus 6P owners who don't get rid of it like to reboot their phones every few days to restore speed, something not needed by people who have taken the cure, thanks to entropy with zram processing) and manufacturers think that this lipstick will look even more red on the pig if they increase the compression ratio.
Stealing CPU resources that you need a lot more than you need RAM.
Go ahead and look in /system/etc/init.qcom.zram.sh on your Moto - please don't take my word for it.
Moto has followed in the new Chinese tradition of changing what that file does, ignoring that Qualcomm said in the comments, in plain English, to only do this for phones without enough RAM.
The Moto doesn't qualify and doesn't need it by design.
You can also see that all it does is call the toybox command to turn it off right after boot, at the end of initialization.
I left the original Moto contents in place because the OP asked late at night for some help when Kernel Adiutor took the turn-off feature away and I never got back to help with something that looked prettier. (And nothing bad on Kernel Adiutor, zram implementation and proliferation is getting to be a burden for maintenance, I don't blame them.)
Past the comments, Moto did not leave the original Qualcomm code in place.
The canonically correct no-swap fix for your phone would be to go in to the ramdisk in the boot image and remove where it gets turned on in the first place.
And then have to redo the mod every time Moto updates that.
Ain't nobody got time for that, and I don't own this phone, I'm helping friends solve this problem with the easy button.
My method leaves the zram declaration in place (you can see it in /proc/partitions) but it's harmlessly unused after the mod.
To learn more about the state of your memory and get some simple explanations without all the voodoo, check out "RAM Truth"
https://play.google.com/store/apps/details?id=sa.ramtruth
It doesn't spy on you, it has no ads or tricky revenue games, it's something that two of us provided as a labor of love for the Android community because after a lot of years, we were repeating the same answers to the same questions.
Knowledge is power ok.
And if you disagree with me about how zram sucks and needs to have a stake driven through its heart, flash the bit that restores your phone to the way it was when you got it and enjoy it in good health. About one in a thousand go that way and that's fine. No need for debate.
Android is all about choice.
Hope this clarifies, thanks for reading, sorry for typos, this was all just flow of consciousness without editing.
Click to expand...
Click to collapse
Wow,
Ok, so next question...
How do you modify the zram partition size?
MadGoat said:
Wow,
Ok, so next question...
How do you modify the zram partition size?
Click to expand...
Click to collapse
You may find an app that will help you with that or you're going to have to modify the ramdisk.
Good luck improving performance. It's not going to happen but good luck, the exercise will probably be revealing.
EarlyMon said:
You may find an app that will help you with that or you're going to have to modify the ramdisk.
Good luck improving performance. It's not going to happen but good luck, the exercise will probably be revealing.
Click to expand...
Click to collapse
Fully understand the performance impacts zram has now... And thank you for the explanation!
I however only have 2gb on this phone and zram has shown to be utilized to about 300 MB. However the zram partition is set at 512mb. It's like to play with 256 or 384 if I can. Ex manager allows zram partition sizes, however I would rather permanently change instead of an "after boot" tweak...
I see in the aforementioned file:
setprop ro.config.zram true
#Set per_process_reclaim tuning parameters
# BEGIN Motorola,IKSWM-36235
#echo 1 > /sys/module/process_reclaim/parameters/enable_process_reclaim
# END Motorola,IKSWM-36235
ProductName=`getprop ro.product.name`
if [ "$ProductName" == "msm8952_64" ] || [ "$ProductName" == "msm8952_64_LMT" ]; then
echo 10 > /sys/module/process_reclaim/parameters/pressure_min
echo 1024 > /sys/module/process_reclaim/parameters/per_swap_size
else
echo 50 > /sys/module/process_reclaim/parameters/pressure_min
echo 512 > /sys/module/process_reclaim/parameters/per_swap_size
fi
echo 70 > /sys/module/process_reclaim/parameters/pressure_max
echo 30 > /sys/module/process_reclaim/parameters/swap_opt_eff
I am not seeing a partition size here...
Swap partition is 512mb.
I've updated the first post to include flashable zips so it's easier to go back and forth if you don't like it.
Elemental kernel installed this does not kill zram.
MadGoat said:
Elemental kernel installed this does not kill zram.
Click to expand...
Click to collapse
Don't know what to tell you, this is for the stock rom/kernel.
MadGoat said:
Fully understand the performance impacts zram has now... And thank you for the explanation!
I however only have 2gb on this phone and zram has shown to be utilized to about 300 MB. However the zram partition is set at 512mb. It's like to play with 256 or 384 if I can. Ex manager allows zram partition sizes, however I would rather permanently change instead of an "after boot" tweak...
I see in the aforementioned file:
setprop ro.config.zram true
#Set per_process_reclaim tuning parameters
# BEGIN Motorola,IKSWM-36235
#echo 1 > /sys/module/process_reclaim/parameters/enable_process_reclaim
# END Motorola,IKSWM-36235
ProductName=`getprop ro.product.name`
if [ "$ProductName" == "msm8952_64" ] || [ "$ProductName" == "msm8952_64_LMT" ]; then
echo 10 > /sys/module/process_reclaim/parameters/pressure_min
echo 1024 > /sys/module/process_reclaim/parameters/per_swap_size
else
echo 50 > /sys/module/process_reclaim/parameters/pressure_min
echo 512 > /sys/module/process_reclaim/parameters/per_swap_size
fi
echo 70 > /sys/module/process_reclaim/parameters/pressure_max
echo 30 > /sys/module/process_reclaim/parameters/swap_opt_eff
I am not seeing a partition size here...
Click to expand...
Click to collapse
Instructions were clear - if you want to mess with it further, use an app or modify the ramdisk.
If you don't know how to modify the ramdisk, use an app.
Pretty sure this thread is about how to use the tool provided to turn it off as noted above, for the stock system.
Related
Hey guys i think this should be an important challenge to overcome maybe find out where all the ram is going and get it back without reseting our precious moguls. My experience its something that Task manager doesn't show up because when i end task on my DCD 3 1 2 ROM i dont get all of my memory back like right after reset. Also this causes inconvinient problem of starting GPS after few days of RAM going down to 8mb and not having enough to lunch TOMTOM.
Oxios doesn't not regain full mem only one third of it.
Can we some how make a better task manager or maybe purge RAM?
Writing a driver to consider our FLASH cards as constant RAM?
I would gladly sacrifice remove ability of my MicroSD for extra 4 gigs of ram and would let my memory leak on a period of roughly 4 years of constant usage.
Please lets get organized and stop hoping the next ROM upgrade will solve this issue.
This is one of the biggest downfalls of the mogul
I would suggest looking into how RAM works before making this thread.
First off, most of our ram appears to be lost due to memory leaks.
http://en.wikipedia.org/wiki/Memory_leak
And since, at least in my experience, most of the memory leak comes from Windows 6 (and so much worse in 6.1), you can't exactly end the windows task unless you...
restart the Mogul.
So no, an application, or task manager, wont do you any good. Not until they fix windows 6.1 up to not be lord of memory leaks. That is why new roms are often so desired, because only a rom release with some decent version of 6.1 with hopefully some patched memory leak holes could help our problem.
Second, you can't use a flash drive as ram, at least its not reasonable. You think the Mogul slows down now? Wow, just wait to you see it moving at the blistering pace of a microSD card.
Ram is so small, and so expensive, largely due to its speed. Thats why you can buy a 500GB HD for about the cost of 4GB of RAM on your computer.
Also, running from the MicroSD would be similar to the page file on your home computer. It runs from, in most cases, your C drive, its a fairly large file, getting even larger when you run multiple tasks on a low RAM system.
It is slow as a dog, and is one of the worst causes of system slowdowns. I also believe that MicroSD's have a limited number of read/writes. While not an issue so much for everyday use (taking pictures, running an app from time to time), if it were used as a swap file, it would probably wear out that SD card pretty quick.
So no, short of an amazing, simple amazing, piece of software engineering on Microsoft's part on a new Windows Mobile, someone developing some sweet, easy to install ram upgrade, or the new replacement for the Mogul coming out with more ram than we know what to do with.
You will be restarting your Mogul.
It should be possible to wright a Driver to USE RAM for swap file and some of main drivers but MicroSD card to be used to run all the extra features and programs. Also why our team of coders cant plug the memory leaks or find out the runing programs not seen by Task manager and have option to close them?
PS
Thanks for confirming my worst dream about the limits of our mogul. Also I notice that PPC on palm trios seems not to have these memory leaks.
This is maybe possible if we can build a tool that can reboot the shell without rebooting the actual OS. It can be combined with the command to free the memory when the OS is unloaded. This is my theory, i think that we can recover memory like this
VulnoX said:
I would suggest looking into how RAM works before making this thread.
First off, most of our ram appears to be lost due to memory leaks.
http://en.wikipedia.org/wiki/Memory_leak
And since, at least in my experience, most of the memory leak comes from Windows 6 (and so much worse in 6.1), you can't exactly end the windows task unless you...
restart the Mogul.
So no, an application, or task manager, wont do you any good. Not until they fix windows 6.1 up to not be lord of memory leaks. That is why new roms are often so desired, because only a rom release with some decent version of 6.1 with hopefully some patched memory leak holes could help our problem.
Second, you can't use a flash drive as ram, at least its not reasonable. You think the Mogul slows down now? Wow, just wait to you see it moving at the blistering pace of a microSD card.
Ram is so small, and so expensive, largely due to its speed. Thats why you can buy a 500GB HD for about the cost of 4GB of RAM on your computer.
Also, running from the MicroSD would be similar to the page file on your home computer. It runs from, in most cases, your C drive, its a fairly large file, getting even larger when you run multiple tasks on a low RAM system.
It is slow as a dog, and is one of the worst causes of system slowdowns. I also believe that MicroSD's have a limited number of read/writes. While not an issue so much for everyday use (taking pictures, running an app from time to time), if it were used as a swap file, it would probably wear out that SD card pretty quick.
So no, short of an amazing, simple amazing, piece of software engineering on Microsoft's part on a new Windows Mobile, someone developing some sweet, easy to install ram upgrade, or the new replacement for the Mogul coming out with more ram than we know what to do with.
You will be restarting your Mogul.
Click to expand...
Click to collapse
while every single statement you say is true, your only wrong about how long ti takes to wear out a flash device. According to Toshiba, the inventor of Flash memory and one of the top suppliers of Flash memory chips, the 10,000 cycles of MLC [Multi-Level Cell] NAND is more than sufficient for a wide range of consumer applications, from storing documents to digital photos. For example, if a 256-MB MLC NAND Flash-based card can typically store 250 pictures from a 4-megapixel camera (a conservative estimate), its 10,000 write/erase cycles, combined with wear-leveling algorithms in the controller, will enable the user to store and/or view approximately 2.5 million pictures within the expected useful life of the card.
For USB flash drives, Toshiba calculated that a 10,000 write cycle endurance would enable customers to completely write and erase the entire contents once per day for 27 years, well beyond the life of the hardware.
take into note that is only 10,000 write cycles. 100,000 which is common for most flash drive now a days. so no, he wont even be around to see the day his flash drive even wears out. LOL.
Glad to see this post picking up some steam But lets Try and focus on making A solution rather than discussin known facts
the known facts have already pointed out the problem (memory leaks in the OS) and the only solution we have without the source code (restart the OS by rebooting the phone) so what else is there to discuss?
oh yeah, we can talk about ways to get the source code so we can fix it.
well i posted one idea:
http://forum.xda-developers.com/showpost.php?p=2257436&postcount=4
Developers please help. It seems that our Nexus Ones are restricted to only 180 MB RAM as their is a bug in the kernel. Can anyone make or compile a RAMhack that can open up the extra 100-150 MB RAM. The below is an excerpt from another thread under the Nexus One - Nexus One forum here in XDA. Im wondering how much faster this thing will fly. It seems a MEMhack such as the one they used to free the 10MB for the dream might be the same approach. Apparently Google will patch this but there is no ETA on the next update.
A "memhack" kernel update in the next Nexus One OTA should give us an additional 100-150MB RAM. Who wants to try to compile a kernel that does this now?
reserved for space
flak0 said:
Developers please help. It seems that our Nexus Ones are restricted to only 180 MB RAM as their is a bug in the kernel. Can anyone make or compile a RAMhack that can open up the extra 100-150 MB RAM. The below is an excerpt from another thread under the Nexus One - Nexus One forum here in XDA. Im wondering how much faster this thing will fly. It seems a MEMhack such as the one they used to free the 10MB for the dream might be the same approach. Apparently Google will patch this but there is no ETA on the next update.
A "memhack" kernel update in the next Nexus One OTA should give us an additional 100-150MB RAM. Who wants to try to compile a kernel that does this now?
Click to expand...
Click to collapse
it's really only a matter of time on this ... once the 2.6.3x kernel is perfected for the mahimahi HW ... we'll get it. Think tank not really necessary ... as it's in the works.
~enom~
Ummmm. I thought that was the goal here:
http://forum.xda-developers.com/showthread.php?t=616383
Doubt we need the 2nd thread.
That is correct that is the goal however, until the .32 kernel is perfected is there a way to hack the current Kernel like it was done for the Dream to get the extra memory back. I am just making a suggestion. I know the only issue with the .32 kernel is the proximity sensor fails from what I have read. Can this be confirmed?
All sensors work fine with 2.6.32. Google put the sensor code in git a few days ago. I am having issues with the camera, but another person in the kernel thread said he got it working, but I can't confirm it yet.
As for the memory hack, I do not know how to do it, but the memory map and allocation are in <kernel dir>/arch/arm/mach-msm and the two files are line 959 in board-mahimahi.c and board-mahimahi.h has the memory map table breakdown.
Edit: I just got the camera working
Wont enabling that ram for program use affect the GPU(Like on the G1)?
~~Tito~~ said:
Wont enabling that ram for program use affect the GPU(Like on the G1)?
Click to expand...
Click to collapse
No, there is ram that isn't even allocated in the nexus unlike the G1. You would just move everything around and nothing would be adversely affected (in theory).
staulkor said:
No, there is ram that isn't even allocated in the nexus unlike the G1. You would just move everything around and nothing would be adversely affected (in theory).
Click to expand...
Click to collapse
Thats a bug google said would be fixed and more ram would be avail for the Nexus.
According to swetland, the only way is via the .32 kernel due to the problems caused by the 1:1 requirement. Otherwise it sounds like things go bad very quickly.
swetland said:
Roughly 220MB is available to userspace in the shipping build (ERD79).
Quite a lot of memory is dedicated to the radio firmware (41MB), dsp firmware (32MB), display surfaces (32MB), gpu (3MB), camera (8MB), a/v buffers (41MB), and dsp buffers. Much of this needs to be set aside for these specific tasks due to hardware requirements of very large physically contiguous buffers which can be difficult or impossible to obtain after boot once the physical memory space gets fragmented.
The big limitation though is that the Linux kernel needs to do a 1:1 physical:virtual map of general purpose memory used by the kernel and userspace (which excludes the special purpose stuff described above). This eats into the available kernel virtual address space, which is also needed for cross process shared memory used by the binder, etc. Run out of virtual memory and things get unhappy.
In 2.6.32, HIGHMEM support for ARM will allow us to avoid this requirement for a 1:1 mapping which will allow us to increase memory available to userspace without running the system out of virtual memory adddress space.
Click to expand...
Click to collapse
bofslime said:
According to swetland, the only way is via the .32 kernel due to the problems caused by the 1:1 requirement. Otherwise it sounds like things go bad very quickly.
Click to expand...
Click to collapse
Thanks for the details. I wasn't aware of what was causing the problem before reading this. This makes a lot of sense.
I've had my suspicions about this since I first got the Droid X2. I think it may be possible for much of the lag many (most/all?) people experience at some time or another.
As a test, I can check free RAM in Advanced Task Killer when I first boot up the phone, and it will hover somewhere 150 megs with all user processes killed.
Then, when I check after 24 hours of constant use (with intermittent charging periods) I will struggle to get 100 megs with all user processes killed.
Finally, if I reboot the phone, I will be able to obtain a decent amount of freed-up RAM again.
Anyone experiencing anything similar?
Now, I must mention, I'm operating under the assumption that the X2 does not cache apps or files in the RAM. I suspect there is too little RAM at such a minimal speed to be able to clear RAM fast enough in the event that something non-cached is called on. I mean, even Microsoft was slow to use this cache method, as they first introduced it in Windows 7. A good example of this in Windows 7 is if you check the Task Manager, you will see that roughly only a quarter of your RAM is ever actually labeled as "free", even if you currently have no programs open or are using minimal amounts of RAM.
And it certainly doesn't feel as if the cache is working as intended if Motorola did infact implement it on our phones.
I have contimplated over this for quite some time and have also came to the same conclusion. But the real question is: What can we do about it?
Most likely nothing.
Not sure of this is actually the case but when V6 is ran for instance it does talk about cached apps and gives an "actual" free ram reading. I would guess that zepplinrox would not have worded it that way if it was not the case but I have no real evidence either way.
Sent from my DROID X2 using xda premium
This did happen to me when I ran Advanced Task Killer on cm7. I'd start with a very good 190 free ram (insane I know) and after a few hours I'd struggle to brake 110
Sent from my DROID X2 using Tapatalk 2
This is the nature of Android and Linux in general. When you start an app (or a process), it will remain in memory until it is cleared by the OS. The problem with task killers and Android 2.3.x and above is this: Android 2.3.x and above RESPAWN the killed task since the OS did not kill it. Plus, there is no way to FORCE to OS to kill an app that is in the background. What Android does is renice the process until it is a positive number, greater than 1, then it kills the process. Android 2.3.x was designed to "auto manage" those tasks. If you run htop from an ADB session and launch apps and use the back button to back out of them, you will notice that the amount of free memory diminishes. Then, after sitting for a time, the amount of free memory slowly begins to increase. When an app that requires a bunch of memory is launched, the Android will kill those background apps to free up more memory. In theory, it is a great way to manage the memory. In this respect, apps that have been launched in that past will start up faster. Personally, I like having control over things. You could possibly write a script that will renice a process to something like +20 and then Android will kill it automatically, but that would be a very risky prospect as it might kill RUNNING foreground apps as well.
Hope this little explanation helps!
Ciao!
DX2 Version History lesion / Android Process Cache
theredvendetta said:
I've had my suspicions about this since I first got the Droid X2. I think it may be possible for much of the lag many (most/all?) people experience at some time or another.
As a test, I can check free RAM in Advanced Task Killer when I first boot up the phone, and it will hover somewhere 150 megs with all user processes killed.
Then, when I check after 24 hours of constant use (with intermittent charging periods) I will struggle to get 100 megs with all user processes killed.
Finally, if I reboot the phone, I will be able to obtain a decent amount of freed-up RAM again.
Anyone experiencing anything similar?
Now, I must mention, I'm operating under the assumption that the X2 does not cache apps or files in the RAM. I suspect there is too little RAM at such a minimal speed to be able to clear RAM fast enough in the event that something non-cached is called on. I mean, even Microsoft was slow to use this cache method, as they first introduced it in Windows 7. A good example of this in Windows 7 is if you check the Task Manager, you will see that roughly only a quarter of your RAM is ever actually labeled as "free", even if you currently have no programs open or are using minimal amounts of RAM.
And it certainly doesn't feel as if the cache is working as intended if Motorola did infact implement it on our phones.
Click to expand...
Click to collapse
Your question is a bit complex. See back when Droid X2 first was released it had 2.2.3 for most users, and didn't have very good application memory management. This was the start of many applications such as "Advanced Task Killer" that you mentioned. These apps were supposed to help in closing apps that were running all the time.
Things changed a bit with the Gingerbread (2.3.3) release. This initial release made the Droid X2 useable. In my opinion the DX2 prior to Gingerbread was nearly a brick! I had many reboot issues, FC, connection issues, GPS issues, etc. With 2.3.3 many issues were eliminated, while others were reduced enough that they didn't bother me TO bad.
2.3.4 came out to fix battery issues largely...
Now I realize you weren't asking for a history lesion, but it is useful to know these things to know where things were and where things are today. I am currently running 2.3.5/412 and have been for months. I can say from experience, Android DOES cache background processes. I thought it did back in 2.3.4, but i can't remember... I don't think it did back in 2.2.x or at least the OS didnt' inform the users via GUI.
Your question about performance though? Yeah the DX2 is crap! I love the physical layout, but it has MANY issues with performance... some have been reduced by doing build.prop edits, yet I have realized that many who post these edits have posted wrong.... for example, they are increasing the buffer sizes thinking this will help internet speeds. This is super complex, but Google "Buffer Bloat" and you'll see how larger buffers often mean greater throughput, but MUCH greater latency....
simply put... big buffer == faster download of individual files.... smaller buffer == slightly slower download but MUCH more responsive
I'm not sure if that answered your question or not... let me know how I did or if I just rambled perhaps =P
I've been playing around with my kernel lately and got caught up in researching in what actually the device reserves itself and where all that memory goes to that's not available to the user-space.
To keep things short here's a breakdown of the biggest users:
Code:
62464kB FIMC0
15360kB FIMC1
12080kB FMIC_IS
71680kB ION heap allocation for FIMC
50176kB MFC secure
4096kB MFC normal
These values are defined in the defconfig and structured into S5P device resources in mach-midas.c, device drivers being in /drivers/media/video/samsung/{mfc5x|fimc|ump} and the ION allocator in drivers/gpu/ion/.
There's several other resources out there including things like the framebuffer (only 8MB, contrary to popular belief and myth) and so on but hey are largely insignificant. The above resources eat up 202MB of reserved kernel-space alone at all times;
FMICx are the Exynos camera interface S5P device resource allocations for the camera firmwares themselves.
FMIC_IS is the memory block for the imaging subsystem.
The ION memory allocation is used by the video systems and MFC for a Video4Linux driver for playback and composition of media.
MFC is the Multi Function Codec a.k.a. the hardware decoder and encoder, this is the memory heap it uses while decoding things.
I already tried messing with the allocated spaces by reducing them and even removing them but anything less than the stock values causes the camera to crash and hardware video decoding to fail (software works without a hitch). Everything else works fine on the phone and you have 950+mB of user-space available memory instead of the 777mB we have right now.
I also tried screwing around with the memory management unit of the MFC as it seemingly had the possibility to use the subsystem used for the Mali memory through something called VCM (Virtual Contiguous Memory) but the latter part seems to be something outdated and no longer supported by the kernel and also haven't found anything newer about it since 2010. Regardless of that, it would have still been something allocated via vmalloc() and thus still residing in kernel-space.
The two possibilities I envision are:
That we somehow manage to clear up the DMA memory whenever any of the features are not used, especially the camera systems since they take up 150MB of RAM at all times.
ION is capable to have user-space CMA blocks reserved, one would have to write a user-space programm/service to detect whenever the systems are needed and allocate the memory spaces like that, and make it work.
Both are quite complex tasks, but the return on investment(effort) would be around 200MB of more usable RAM in daily operations, which is basically is a 25% boost in usable memory.
Different systems (HTC OneX I believe) already do without some of these device memory blocks (979mB user-space), although I'm not familiar on how or what they use.
This thread is meant as an idea-gathering and discussion on how to approach this and the feasibility of it, and I hope some souls can add something to it.
Andrei,I always loved your more advanced than average stuff.This is no exception.
Anyway,I just had a crazy idea.What if we could make these take up swap space?I mean,Gokhanmoral's kernel let's you create a swap file.Would it be possible to get these to take the swap space and reside there until needed?Maybe we could trick the kernel into thinking that swap is an extension of RAM and not swap or something.That would be cool.
Kernel-space memory is not swappable nor is there any magic trick to somehow circumvent this basic rule, else it would have already been done.
I found a quite nice graphic in a presentation [here] which describes the memory model:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Basically, we're dealing with the blue stuff here, if I'm not mistaken on how the S5P device handler allocates it.
Andreilux sorry disturb you but...
Looking today the app System Tuner Pro using Siyah Kernel i saw a lot configs ram related inside sysctl and buildprop tabs can you only see if any these option can help our ram problem?
Enviado do meu GT-I9300
Afaik the drivers in linux phones usually use a predetermined fixed physical address ... Without the sources i see difficult force to use userspace.
That is not true for the Android OS, as back on the Captivate, one of the best Kernel devs I know gave us like 403MB of user space in RAM when the stock value was like 337MB or something in that area. He took some of the memory from GPU, camera, and system!
b-eock said:
That is not true for the Android OS, as back on the Captivate, one of the best Kernel devs I know gave us like 403MB of user space in RAM when the stock value was like 337MB or something in that area. He took some of the memory from GPU, camera, and system!
Click to expand...
Click to collapse
It was a lot easier on the Hummingbird platform...less chance to break something
Here on the S3 platform everytime a value is changed it breaks the feature which is related at. It makes no sense theorically but maybe the hardware NEEDS that space as per firmware design.
I think the only way is to find out how the Tegra 3 plaform dynamically allocates that memory and port it over Exynos.
Sent from my GT-I9300 using Tapatalk 2
AndreiLux, this sounds absolutely amazing! Great work!
It amazes me how Samsung can have so many design wins in one product, and how many small things that don't really make a lot of sense (that our friendly devs are then tasked with fixing! )
I think it may be worth spending time on this. S3 already has solid multi-tasking once you clear out bloat ware, so I'm creaming my panties thinking what it'd be like with more ram! (I'm surprised Tegra 3 works better in this respect since most Tegra 3 phones don't have good multi tasking!)
I don't really donate to devs (apart from buying some paid versions of apps ), but if you manage to pull this off, I certainly want to 'buy you dinner'!
Good luck, everyone!
Sent from my GT-I9300 using xda premium
If you managed to pull this off it would elevate you to superstar status in this community. This would be huge for the SGS3 especially now with RAM hungry JB Rom's springing up all over the place
You would become an overnight XDA legend and deservedly so.
But.......can it be done? Over to you Andrei
New version XXDLH9 JB coming with 818mb ram now.
Samsung increase 30mb.
JB source please.
Enviado do meu GT-I9300
Andrei
There was be the same on the galaxy s1,
Some kernel makers, released a bigmem version, that breaks hd playback and camera, and one of them, was hardcore... maybe you can ask him, how they solved that on galaxy s1...
They fixed hd and camera, and all is working on the bigmem versions on the gs1...
What i would say, maybe in the gs1 section, you would get your answers...
Cheers
I'm already running at 832mB now without issues in Perseus. And to be honest I don't care what happened on the S1, what those devs did, I already did myself before I wrote this, I'm more interested in conditionally allocating these spaces which is much harder and trickier.
Funny though that LH9 has more space now... would be curious to see the changes. If it's the same, then I "wasted" a day or two of testing.
What happens in a situation where the free memory is low because of userspace processes, and the camera stuff needs to start working? Assuming no swapping mechanism is being used, of course.
Before doing the required memory allocation for FIMC, is it feasible for the kernel to synchronously invoke the LMK to make some userspace processes go away to make space in physical memory for the new kernel memory area?
AndreiLux said:
I'm already running at 832mB now without issues in Perseus. And to be honest I don't care what happened on the S1, what those devs did, I already did myself before I wrote this, I'm more interested in conditionally allocating these spaces which is much harder and trickier.
Funny though that LH9 has more space now... would be curious to see the changes. If it's the same, then I "wasted" a day or two of testing.
Click to expand...
Click to collapse
Interesting to see that Sammy, too, is going a direction to have more RAM usable, they must have noticed they just gave the device too little...
Any way to have a look behind the scences on what / how you did it to get the extra 45-50Mb RAM ? (github ?) I'd be rather keen on modding my kernel in such a way, too, until there's a way to go the whole nine yards with dynamic allocation.
I could really do with more available RAM
As for using the LMK to free up space to dynamically for the camera etc., I don't think that was the intended design of the LMK ... I don't understand anyway why Google added the LMK wrap instead of tweaking Linux OOM to take care of freeing RAM.
JP.
PS: Wow, just noticed, you're the first fellow country-man I stumble on on xda With Luxembourg beeing so small, we wouldn't happen to know each other ??
EDIT : Forget my question about GitHub, I should know better : "to first search, ask questions later"
Yank555 said:
As for using the LMK to free up space to dynamically for the camera etc., I don't think that was the intended design of the LMK ... I don't understand anyway why Google added the LMK wrap instead of tweaking Linux OOM to take care of freeing RAM.
Click to expand...
Click to collapse
When I mentioned LMK I was thinking of the mechanism in a broad sense, including OOM (I just had a look at mm/oom_kill.c which I didn't know about).
It looks like the logic is already there, but it's still required to understand whether it will kick in automatically - it looks like it's triggered automatically by pagefaults, but do these also occur on the kernel code? - if it makes a difference to have OOM sending SIGKILL instead of letting the processes be aware of termination (SIGTERM, or whatever LMK does), how can the physical areas be shifted (changing the virtual mappings) if that's important for the FIMC buffers, etc.
I guess this is already common knowledge for you guys. Don't mind me then, I'm just thinking out loud as this is new to me
Tungstwenty said:
When I mentioned LMK I was thinking of the mechanism in a broad sense, including OOM (I just had a look at mm/oom_kill.c which I didn't know about).
It looks like the logic is already there, but it's still required to understand whether it will kick in automatically - it looks like it's triggered automatically by pagefaults, but do these also occur on the kernel code? - if it makes a difference to have OOM sending SIGKILL instead of letting the processes be aware of termination (SIGTERM, or whatever LMK does), how can the physical areas be shifted (changing the virtual mappings) if that's important for the FIMC buffers, etc.
I guess this is already common knowledge for you guys. Don't mind me then, I'm just thinking out loud as this is new to me
Click to expand...
Click to collapse
I'm just getting into this, too
We had a memory issue on a kernel on Sensation, which is why I've been digging a little into this stuff in the last few days / weeks
I've not gotten to try to understand the fundamental difference between OOM and LMK, just noticed what may be one of the fundamental differences, LMK considers cache memory blocks to be free, and even though I've not checked OOM, I'd think it's not the same for Linux OOM.
But I'll stop here, I think we're maybe drifting away from the topic
If pagefaults trigger OOM mechanisms, or free memory dropping below a threshold for LMK, it should be possible to trigger those when for example the camera driver is needed.
Maybe upping the LMK limits above the size of what is needed could do as well, as those would have LMK kick in, thus freeing RAM to at least that level ...
On the other hand I suppose what will be needed here is a big contiguous memory area, so freeing RAM alone wouldn't be enough if it's fragmented, a memory compactation would need to be triggered as well to ensure a sufficiantly sized bontiguous area of memory becomes available...
JP.
EDIT: Just thought of another detail, if kernel memory and userspace memory are two big contiguous memory areas (don't know this), the freed block whould need to be in the userspace block at the boundary of the kernel space block ? Since we would have to move that boundary ... to get userspace to kernel space ?
@ andrei and other experts here
Wanted to know something, as samsung has increased the free memory from 778 mb to 818 mb(40 mb higher) its clear that the additional 40 mb has been released from FMIC,ION,MFC blocks. my query is what impact it would have on the functionality of these blocks? also as samsung has done it officially in their rom it can be considered that there may be no impact but why did samsung didnt do it in the first place?
bala_gamer said:
@ andrei and other experts here
Wanted to know something, as samsung has increased the free memory from 778 mb to 818 mb(40 mb higher) its clear that the additional 40 mb has been released from FMIC,ION,MFC blocks. my query is what impact it would have on the functionality of these blocks?
Click to expand...
Click to collapse
If it was possible to look at their changes (sources) ... But the impact shouldn't be big / noticeable, else I doubt they would have done it...
JP.
Yank555 said:
Maybe upping the LMK limits above the size of what is needed could do as well, as those would have LMK kick in, thus freeing RAM to at least that level ...
Click to expand...
Click to collapse
True, but in practice that would be the equivalent of having less free memory because for all purposes the OS would start killing processes earlier, right?
So we need to keep a lighter limit on LMK (for RAM to actually be used for multiple open processes), but still be able to trigger it synchronously when RAM needs to be "reduced" to make space for the kernel memory for FIMC / whatever.
Yank555 said:
On the other hand I suppose what will be needed here is a big contiguous memory area, so freeing RAM alone wouldn't be enough if it's fragmented, a memory compactation would need to be triggered as well to ensure a sufficiantly sized bontiguous area of memory becomes available...
JP.
EDIT: Just thought of another detail, if kernel memory and userspace memory are two big contiguous memory areas (don't know this), the freed block whould need to be in the userspace block at the boundary of the kernel space block ? Since we would have to move that boundary ... to get userspace to kernel space ?
Click to expand...
Click to collapse
About it being continuous and/or needing to be on the boundary, that's exactly my point about whether virtual address remapping is required or not. Virtual remapping might be enough, bit it could also be the case that physical map needs to be compacted or reordered, and virtual mapping be fixed so all pointers keep working as before.
bala_gamer said:
@ andrei and other experts here
Wanted to know something, as samsung has increased the free memory from 778 mb to 818 mb(40 mb higher) its clear that the additional 40 mb has been released from FMIC,ION,MFC blocks. my query is what impact it would have on the functionality of these blocks? also as samsung has done it officially in their rom it can be considered that there may be no impact but why did samsung didnt do it in the first place?
Click to expand...
Click to collapse
As far as I can see, no effects outside of extreme conditions. You'll be able to test it yourselves soon.
Our device isn't considered to be powerful anymore. It's became an complete underdog. Thanks to Android's flexibility, you can force to make your phone pretty much fly with several tweaks.
1. Delete as much bloatware as possible.
This is regarded as an easiest, noobiest option to improve your phone's performance. Many OEM apps stays hibernated in the RAM, thus limiting free RAM available to the user and sometimes even stressing NAND too much. In the end, it's the best to keep your phone as clean and deleting useless apps on the fly.
2. Don't install too much apps into NAND memory
Benchmarks shown, that our phone's NAND chip is considered to be rather slow. Since many apps access small amounts of random data pretty much constantly, it's better to have less apps installed on your phone.
3. Avoid using app killers
This is a placebo effect, since Android's memory management is inferior to what app killers are doing. Many apps stays in such state, where they are ready to be launched almost instantly. App killers, however, pretty much screw all the mandatory functions and stresses the phone even more than before. Launcher redraws are rather common occasion when app killer is being used.
4. Use custom kernel
Custom kernels often offer more features and are more optimized to make the use of available hardware. OEMs never seem to mess around with kernels much, since they want to have their product as stable as possible. Devs, however, mess around with kernels and extract almost double the real-time performance.
5. Never fill up your storage completely
The more data is available on the storage, the harder is getting to find it. Since data is laid randomly, it searches for the information location. When there are too much data, it gets harder to find the data needed. Often slower cards, like Class 2 or Class 4, are considered to be the better choice, since those cards are much faster at writing and reading marginal data randomly.
6. Select the I/O scheduler, CPU governor wisely
These things manipulate with the main hardware. The better optimized the governors are, the better the phone will run and won't drain the battery as much. Though keep in mind, that many governors have their own drawbacks.
sioplus is one of the better I/O schedulers. It allows access to random data pretty quickly, which ensures smooth and snappy performance in the system.
ondemand is the most common and is the stapple and the base of many custom governors available today. It's method is pretty simple - whenever phone registers a touch input, it automatically raises the CPU speed to the max. In retrospect, it should give great performance, but it usually suffers from poor response.
7. Play around with Dalvik VM settings
My optimized settings (feel free to use them):
dalvik.vm.heapstartsize=6m (size when first launched)
dalvik.vm.heapgrowthlimit=64m (limit of standard app)
dalvik.vm.heapsize=192m (heap for large app)
These settings pretty much controls our multitasking. Each phone has it's own specified settings, so it could run better.
Lowering these settings could majorly improve performance, but it could slow down around, when there too much heavy apps running in the background.
Raising these settings could improve multitasking, since less CPU power is required to extract certain data to the RAM. Scrolling a heavy webpage, for instance - raising these settings could improve scrolling smoothness and loading times, since there isn't a need to clean the heapsize as frequently as it was before.
More suggestions are coming later. If you found this article useful, please leave THANKS!
Good day.