Wanna have a faster device for almost nothing? READ THIS!! - LG Optimus L3 II, L5 II, L7 II, L9 II

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.

Related

Might the X2 have a memory leak?

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

Best memory/governor settings for fascinate

Running build 11 of team hacksungs cm9 ics port. My current governor is on demand with a minimum of 400 and maximum of 1000. There are numerous memory settings in the cm9 settings such as how many background processes run. I wouldn't call myself a power user but I do use my phone for apps and internet throughout the day.
Sent from my SCH-I500 using XDA
I use sio and glitch/smartassv2.
There is never really a "best" selection for these types of setups. They are relevant to how you want your phone to operate. Some choose for performance versus battery. You have to pick what is most important to you but the question may be better phrased if you have stability issues.
I run AOPK ROM but I have always chose performance governor with min and max set to 1200MHz. For memory, the Droidstyle guide I believe references keeping 100mb free.
That combination has worked good enough to prevent lag/delay but provide additional response time for my phone. Battery is decent with moderate use but watch the battery temp. The stock battery is only 1500mA so that is one of the limiting factors.

[Q] extweaks zram

So, using extweaks I see that theres a zram setting thats default is off. I have a couple questions about it. To my understanding, enabling it adds more usable ram for the android system, but it uses cpu to compress it right? So does this mean that it uses more battery life as well? or by adding more ram, will it save battery life because its not having to reorganize system resources all the time. I don't quite understand how it works.
someone enlighten me. My main question is, does it negatively or positively impact battery performance.
thanks
I don't know much about how it works, but I can tell you when I tried to use it it slowed down my system. No positive effects noticed.
aspen1135 said:
So, using extweaks I see that theres a zram setting thats default is off. I have a couple questions about it. To my understanding, enabling it adds more usable ram for the android system, but it uses cpu to compress it right? So does this mean that it uses more battery life as well? or by adding more ram, will it save battery life because its not having to reorganize system resources all the time. I don't quite understand how it works.
someone enlighten me. My main question is, does it negatively or positively impact battery performance.
thanks
Click to expand...
Click to collapse
More cpu work load = more battery drain , so yes theoretically zram will decrease your battery life but i don't have numbers to prove it . Also your kernel must support zram to use it . I haven't seen a huge performance increase or the like enabling it but multitasking seems more smooth or so it feels to me .
leap before you think

RAM limitation on non-Pro configuration

Hi, I heard MIUI reserves 1GB+ for itself. Can any of non-Pro version owners report 2GB RAM sufficiency for common operation (multitasking, running user apps in background etc.). How much complexity the present memory allows? Is killing apps in background frequent? How about lagging?
Is there any real performance comparison between Pro and non-Pro configuration?
And finally is it worth to drop ~$30 more for Pro version (as about phone smooth performance and fingerprint scanner)
Haven't got the phone, but from research i'm doing, it seem like a big annoying issue.
Hi, I have the 2GB version, but I also have a similar phone with stock Android, so I'm going to compare these two.
Multitasking in MIUI is very tight, don't expect to keep switching to more than 2 apps instantly, there will be lags and loading animation. Yes killing in background is frequent, there is a page on Security app called Autostart that is listing apps that are actually running, and I have never seen more than 4-5 apps tagged as running, assuming you keep autostart off. However, if you tag an app as autostart enabled, even if they're killed they will start again in background, so you won't have problems with notification, at the expense of a little battery life. This is kinda complicated but offers for more control. Notice that app that isn't tagged as running and not autostart enabled is dead dead, no notification, no background process, no battery drain.
I don't think there'll be much different for Pro version in multitasking, I have seen the same thing on Mi 5, it's just the way MIUI works. But yes the $30 is definitely worth it for double the storage, 150% RAM, and fingerprint.
Note that you can disable the background killing in developer options, disable MIUI battery optimization, and tag all apps as autostart enabled, to get better multitasking experience as good as stock Android, but apparently this is not a good idea if the phone is only having 2GB of RAM, the lag is becoming too much in my opinion, because MIUI does keeping around 1GB for itself in this phone. Hope that helps.
I'll keep this short and sweet. Am on latest xiaomi.eu's 6.5.26 dev build for my ido and dare I say it's the best representation of how it should be done for MIUI global rels. Most crufts removed and loose ends tightened. That being said and not that I blame xiaomi.eu's team in any shape or form, they have to work with what they got so suffice to say that MIUI by default could seriously use way better RAM management chops.
If it's just $30 more for Pro and you don't care about a larger screen estate (kenzo), then go for it bro double time.

[Mod] Disable ZRAM [Stock ROM]

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.

Categories

Resources