I've always run compcache on my ROMs when possible and I recently had the idea that setting the full amount of RAM to compcache could be an interesting test. The theory being that it may be slightly slower overall to have ramzswap compressing pages, but minfree would have heaps of memory to play with and apps would never quit, so multitasking would be faster as no apps are writing out to /data and then having to relaunch when I switch to them again.
I've set compcache with the init script like so
Code:
insmod /system/lib/compcache/ramzswap.ko;
rzscontrol /dev/block/ramzswap0 -i -d 98304;
busybox swapon /dev/block/ramzswap0;
And Linux reports the swap is working
Code:
# free
total used free shared buffers
Mem: 107332 105972 1360 0 8
Swap: 98296 48940 49356
Total: 205628 154912 50716
But no matter what I do, even if I launch a heap of apps, I can never get swap usage above the ~48Mb RAM seen here.
Furthermore, apps like Auto Killer and Free Memory only report I have 102Mb RAM total.
What's going on here? Why does Android think it only has 100Mb when free is reporting near on 200Mb total? Why does compcache only fill up halfway and no more? Does this mean that ~48Mb RAM is the "sweet spot" for compcache and any more is pointless?
The phone does feel faster when switching between apps but I could just be imagining it. Out of interest this is a 32B Magic running Dwang 1.17.1, which is basically just Donut AOSP with a faster framework and kernel.
Any ideas/help/suggestions would be appreciated?
Swap is never, ever, regarded by the system as real memory, hence why the system won't report it, since you really only have ~100 mb physical ram.
As to why you're only using 48, I believe that 48 is 1/2 96, so it probably means pages are being compressed 2:1, so the full memory is being compressed and dumped into RAM, and it only occupies 48 MB, leaving you 48 free for other processes.
Again, remember comcapche is swap, not real memory.
jubeh said:
Swap is never, ever, regarded by the system as real memory, hence why the system won't report it, since you really only have ~100 mb physical ram.
As to why you're only using 48, I believe that 48 is 1/2 96, so it probably means pages are being compressed 2:1, so the full memory is being compressed and dumped into RAM, and it only occupies 48 MB, leaving you 48 free for other processes.
Again, remember comcapche is swap, not real memory.
Click to expand...
Click to collapse
I don't think that that analysis is quite right....
First off, you MUST maintain SOME amount of real memory available... otherwise it'll crash in a spectacular way. I believe that the linux kernel itself may have a safety feature that maintains a certain minimum amount of physical ram available. There ARE certain things that the linux kernel will not be willing to swap, such as ITSELF.
Just imagine what would happen if the kernel swapped itself..... any attempt to do this wouldn't end well. Especially if it tried to swap its ENTIRE self since the kernel MUST be in memory in order for it to run.
There is also the swappiness setting... it controls the system's tendency to swap.
And finally, there is the possibility that you may simply not be starting enough processes to consume the full memory!
So imagine this; you have your compcache set for a certain size. It grows to that size and then finally, the kernel says "screw you, you can't have any more memory!" blows an error back to compcache, which complains back to the kernel "sorry, swap is screwed." Yep.... the kernel tells compcache which tells the kernel rather than the kernel just knowing.
You definitely don't want this happening.
Note: I can forsee some serious stability problems that this could result in related to the low memory process killer. Specifically, your compcache grows to its maximum allowed size, you start an application, the low memory process killer figures that you've got plenty of memory available, doesn't kill anything off, tries to start some application, crashes spectacularly when the kernel complains back that it doesn't have any memory. I don't know if this would happen with a stock low memory process killer, but definitely would with the swap hacks added....
lbcoder said:
Note: I can forsee some serious stability problems that this could result in related to the low memory process killer. Specifically, your compcache grows to its maximum allowed size, you start an application, the low memory process killer figures that you've got plenty of memory available, doesn't kill anything off, tries to start some application, crashes spectacularly when the kernel complains back that it doesn't have any memory. I don't know if this would happen with a stock low memory process killer, but definitely would with the swap hacks added....
Click to expand...
Click to collapse
92 MB of compcache doesn't really need 92MB of compcache... that's the point of being compcache.
Compcache file in RAM grows when cache gets stuffed inside compcache.
Setting a low swappiness will cause compcache to just swap what's needed.
And even with full compcache, in the end you end up having around 140 mb (or so) free ram. 92mb of compcache that takes like 50mb and 42 extra mb of normal ram.
I think this idea is great (I was just too lazy to try yet...). Instead of dalvik vm having to free up memory it can stuff some more mb in compcache. should be faster.
I didn't really think my post through... but I hope some of you understood some of the things I wanted to communicate xD
domenukk said:
92 MB of compcache doesn't really need 92MB of compcache... that's the point of being compcache.
Compcache file in RAM grows when cache gets stuffed inside compcache.
Setting a low swappiness will cause compcache to just swap what's needed.
And even with full compcache, in the end you end up having around 140 mb (or so) free ram. 92mb of compcache that takes like 50mb and 42 extra mb of normal ram.
I think this idea is great (I was just too lazy to try yet...). Instead of dalvik vm having to free up memory it can stuff some more mb in compcache. should be faster.
I didn't really think my post through... but I hope some of you understood some of the things I wanted to communicate xD
Click to expand...
Click to collapse
Interesting in theory, but if you actually read what I said, you would note that this is entirely IMPOSSIBLE and would crash spectacularly if not for and in some cases in SPITE of certain safety features built into the kernel.
Note: If you have 70 MB worth of data that CAN'T be swapped, that leaves 20 MB ***PEAK*** available to compcache.
It is neither fair nor sensible to think of all memory as being equal. Running processes ***MUST*** have REAL MEMORY.
A little off-topic, but this discussion (the possibility of REAL "compressed" memory) sparked a thought/question:
Would/could KSM* bring any benefit to Android? (Not sure if the KSM module can even compile/work on ARM)
I know KSM is normally used for detecting and sharing duplicate pages among KVM guests, but I wonder how many pages in a typical running Android installation are duplicated, and thus candidates for sharing/de-duplication.
*I can't posts links yet, so those that don't know what KSM is, will just have to google for it.
lbcoder said:
There ARE certain things that the linux kernel will not be willing to swap, such as ITSELF.
Click to expand...
Click to collapse
I was under the impression the kernel keeps itself in RAM and then reports free memory to the rest of the OS. This is why the phone physically has 192Mb RAM, but only reports 96Mb free (or 107Mb with RAM hack). Perhaps my understanding of Linux/Android memory reporting is not correct?
lbcoder said:
It is neither fair nor sensible to think of all memory as being equal. Running processes ***MUST*** have REAL MEMORY.
Click to expand...
Click to collapse
I think this is likely what is happening. Home, Phone, System and other processes with a low oom are refusing to swap out as they are still running. If the compcache allocation in RAM is dynamic as domenukk says, then those processes are occupying enough RAM that the ramzswap allocation can only grow to ~48Mb as I am seeing. I didn't think of this.
Nor have I tweaked swappiness. It's currently set to 60 (default) so I'd assume it's not too fussy with paging out. I will try playing with this at 10 and 100 to see if I can force anything more into swap or if it's less willing to swap.
brainbone said:
*I can't posts links yet, so those that don't know what KSM is, will just have to google for it.
Click to expand...
Click to collapse
I do not know either, but here are some links people may wish to look at
http://fedoraproject.org/wiki/Features/KSM
http://lwn.net/Articles/306704/
http://lwn.net/Articles/330589/
http://www.linux-kvm.com/content/using-ksm-kernel-samepage-merging-kvm
Ok I am not at all experienced in this area but this is just a suggestion. You say that you can only get 48mb of swap to be compressed at a time. If those 48mb were uncompressed, then that would occupy the 98mb you alloted to it. If you set the cc at say 128mb, then in (my) theory up to 64mb of it the actual ram would be used. I don't know how much sense I'm making but not sure exactly how to explain it. If you don't get it I'll try explaining my logic a little more in depth.
mejorguille said:
If you set the cc at say 128mb, then in (my) theory up to 64mb of it the actual ram would be used.
Click to expand...
Click to collapse
It appears you are right. Even with swappiness set to 100 and opening every app on my phone I'm not able to fill more than half of 128Mb compcache before minfree stats gracefully closing processes:
Code:
/opt/android-sdk-linux_86/tools$ ./adb shell free
total used free shared buffers
Mem: 107332 105956 1376 0 32
Swap: 131064 65520 65544
Total: 238396 171476 66920
Super Jamie said:
It appears you are right. Even with swappiness set to 100 and opening every app on my phone I'm not able to fill more than half of 128Mb compcache before minfree stats gracefully closing processes:
Code:
/opt/android-sdk-linux_86/tools$ ./adb shell free
total used free shared buffers
Mem: 107332 105956 1376 0 32
Swap: 131064 65520 65544
Total: 238396 171476 66920
Click to expand...
Click to collapse
I rock=p
So what's your performance like, compared to say 32mb cc or no cc at all?
It's different but I like it.
There is sometimes a slight (<2 second) pause when launching a new app (I assume this is compcache compressing old pages to swap to make way for the new app) however once the app is up and running, it almost never "exits" so switching between previously-launched apps is noticeably faster than without compcache. I run HelixLauncher Donut and it's never closed and re-launched while I've been trying this, however it did sometimes with 32Mb cc and quite often without cc at all.
I had 5 day uptime last week with 96Mb compcache (rebooted whilst testing another app for a friend) so I don't think stability is an issue. The CM wiki indicates performance with cc is better upon boot then gradually declines, even if that is the case, rebooting my phone once a week is no big issue.
Unless I run into any major issues, I'll be keeping my phone with large compcache
Super Jamie said:
I was under the impression the kernel keeps itself in RAM and then reports free memory to the rest of the OS. This is why the phone physically has 192Mb RAM, but only reports 96Mb free (or 107Mb with RAM hack). Perhaps my understanding of Linux/Android memory reporting is not correct?
I think this is likely what is happening. Home, Phone, System and other processes with a low oom are refusing to swap out as they are still running. If the compcache allocation in RAM is dynamic as domenukk says, then those processes are occupying enough RAM that the ramzswap allocation can only grow to ~48Mb as I am seeing. I didn't think of this.
Nor have I tweaked swappiness. It's currently set to 60 (default) so I'd assume it's not too fussy with paging out. I will try playing with this at 10 and 100 to see if I can force anything more into swap or if it's less willing to swap.
I do not know either, but here are some links people may wish to look at
http://fedoraproject.org/wiki/Features/KSM
http://lwn.net/Articles/306704/
http://lwn.net/Articles/330589/
http://www.linux-kvm.com/content/using-ksm-kernel-samepage-merging-kvm
Click to expand...
Click to collapse
ksm sound cool. As every app runs inside dalvik vm. Not sure though... somebody should ask cyanogen
I am happy thatlarge compcache works out so well for you.
BTW doesn't cyanogenmod 5 count the whole swap as real memory since test4 or so?
Oh and overclocking ondemand to as high as possible will speed up app opening and switching a lot while on compcache
domenukk said:
doesn't cyanogenmod 5 count the whole swap as real memory since test4 or so?
Click to expand...
Click to collapse
It's counted as available "swap" memory, but not "real" ram. Pages stored in "real" ram (memory that the cpu can directly execute code in) still need to be freed up (moved to swap) before previously swapped pages can be moved back in to "real" memory to be executed.
domenukk said:
ksm sound cool.
Click to expand...
Click to collapse
The beauty of KSM is that it does no "swapping". It simply combines 4KB pages that are identical -- so instead of two identical 4KB pages using 8KB of ram, they only take 4KB. The code is executed in place.
KSM would, however, still require swap. If at any time a virtual shared 4KB page is written to, it needs to be copied to a free page to avoid corrupting the virtual page it was a duplicate of before the write. Swap is needed to ensure that there will always be enough available free pages when this happens.
domenukk said:
As every app runs inside dalvik vm.
Click to expand...
Click to collapse
KSM is not dependent on a VM, but the existence of VMs (java or otherwise) increases the likelihood of duplicate pages.
domenukk said:
Not sure though... somebody should ask cyanogen
Click to expand...
Click to collapse
I'd certainly be interested in cyanogen's thoughts on this, but I'm sure there are others that would be able to chime in as well.
Relevant excerpt from kernel.org/doc/ols/2009/ols2009-pages-19-28.pdf
KSM and embedded
KSM is suitable to be run on embedded systems too; the important thing is not to register in KSM regions that won’t likely have equal pages. For each virtual page scanned, KSM has to allocate some rmap_item and tree_item, so while these allocations are fairly small, they can be noticeable if lots of virtual areas are scanned for no good.
Furthermore, these KSM internal rmap/tree data structures are not allocated in high memory. To avoid early out of memory conditions, it is especially important to limit the amount of lowmem allocated on highmem 32bit systems that might have more than 4GB of memory, but these shouldn’t fit in the embedded category in the first place.
Click to expand...
Click to collapse
Super Jamie said:
I was under the impression the kernel keeps itself in RAM and then reports free memory to the rest of the OS. This is why the phone physically has 192Mb RAM, but only reports 96Mb free (or 107Mb with RAM hack). Perhaps my understanding of Linux/Android memory reporting is not correct?
Click to expand...
Click to collapse
Memory reporting is a tricky thing.
But in general, when RAM is allocated to HARDWARE, it is NOT REPORTED.
The chunk of the 192 that is not reported is assigned PRIMARILY to the RADIO. Another chunk is assigned to the GPU. Still more is assigned to the AUDIO HARDWARE.
The part used by the kernel itself IS reported. The most trivial empirical evidence to prove this to you is that when you change KERNELS, it doesn't affect the total system memory, despite your KNOWING that different kernels use different amounts of RAM.
Another bit of empirical proof is that activating COMPCACHE does not reduce the total physical ram reported. And yes, COMPCACHE is part of the kernel...
Now here's another concept of crash and burn: IF everything in memory could be cached in compcache, then what would stop compcache from caching compcache in a horrible infinite memory sucking loop? That would be very very bad, LOL.
I think this is likely what is happening. Home, Phone, System and other processes with a low oom are refusing to swap out as they are still running. If the compcache allocation in RAM is dynamic as domenukk says, then those processes are occupying enough RAM that the ramzswap allocation can only grow to ~48Mb as I am seeing. I didn't think of this.
Click to expand...
Click to collapse
NOW you're getting the idea! Running processes, kernel, etc., all need physical RAM (though actually those processes you mention most definitely CAN be swapped...), and therefore you CAN'T make the ENTIRE RAM into compcache!
Nor have I tweaked swappiness. It's currently set to 60 (default) so I'd assume it's not too fussy with paging out. I will try playing with this at 10 and 100 to see if I can force anything more into swap or if it's less willing to swap.
Click to expand...
Click to collapse
Just beware of possible crash-and-burn
Super Jamie said:
It appears you are right. Even with swappiness set to 100 and opening every app on my phone I'm not able to fill more than half of 128Mb compcache before minfree stats gracefully closing processes:
Code:
/opt/android-sdk-linux_86/tools$ ./adb shell free
total used free shared buffers
Mem: 107332 105956 1376 0 32
Swap: 131064 65520 65544
Total: 238396 171476 66920
Click to expand...
Click to collapse
That doesn't actually follow from what you've posted here.
What follows is that 105956-(65520/2)=73196 of what occupies your memory can't be swapped (kernel, running processes, etc.).
lbcoder said:
What follows is that 105956-(65520/2)=73196 of what occupies your memory can't be swapped (kernel, running processes, etc.).
Click to expand...
Click to collapse
Do you know why swap constantly "settles" at almost exactly half usage regardless of what size compcache I set?
For example, I set 64Mb compcache yesterday and rebooted. Just using my phone normally (browser, genie widget, music) I have this:
Code:
total used free shared buffers
Swap: 63992 32096 31896
Does this mean I am effectively reducing the amount of RAM the phone has for the kernel, "foreground app", "visible app" and "secondary servers" (to use the minfree terms), whilst at the same time allowing more "hidden app" and lower processes to swap out instead of terminating gracefully?
This disturbs me
-------------------------------------
Sent via the XDA Tapatalk App
brainbone said:
I'd certainly be interested in cyanogen's thoughts on this, but I'm sure there are others that would be able to chime in as well.
Click to expand...
Click to collapse
He doesn't know much about it, yet. But he seems inerested.
Attached a short conversation over #twitter
# Dominik domenuk
@cyanogen Is ksm any good 2 save RAM? probably not - you would have already done it http://lwn.net/Articles/329123/
# Steve Kondik cyanogen
@domenuk I don't know too much about it, I think its meant for sharing between distinct virtual machines
@domenuk it could have a lot of potential though
# Dominik domenuk
@cyanogen basically yes. But he states its also for normal apps. I have no idea to what extend android apps have similar memory, though...
# Steve Kondik cyanogen
@domenuk a lot, Android is all about IPC and shared memory. I wouldn't be surprised if the Dalvik people are thinking about it.
Click to expand...
Click to collapse
Here is a way to make Android use more than 50 percent of a swap partition. I am not sure how it will act with compcache... Should be the same... Run the following commands from a terminal or add them following to your userinit.sh file:
Code:
su
echo 80 > /proc/sys/vm/swappiness
echo 150 > /proc/sys/vm/vfs_cache_pressure
!!WARNING!! - Messing with VM settings can cause data loss and system instability... Not liable for damages...
Using the above the "free" output is:
Code:
total used free shared buffers
Mem: 97708 95168 2540 0 356
Swap: 125296 88756 36540
Total: 223004 183924 39080
While we are at it... If anyone is willing... they can try this as well:
echo 1 > /proc/sys/vm/oom_kill_allocating_task
Reference : Article to Linux Insight
Been having pretty good results with it...
Here is a link to the rest of the vm settings...
Linux Insight article listing vm settings
L8r
I wanted to know if we can increase the ram of our little pico (htc Explorer)....also I wanted to know the advantages of swap partition.....Does it increase the ram size ?? And also I wanted to know that if there are any other advantages of Sd-ext partition other than increasing the Internal memory ??
ahmadmemon said:
I wanted to know if we can increase the ram of our little pico (htc Explorer)....also I wanted to know the advantages of swap partition.....Does it increase the ram size ?? And also I wanted to know that if there are any other advantages of Sd-ext partition other than increasing the Internal memory ??
Click to expand...
Click to collapse
No, you can't. Physical RAM is fixed.
Swap acts as pagefile on Windows, if you know pagefile. swap is virtual RAM. When the system needs more memory, a part of RAM will be written to the swap partition. Swap partition is part of SD card, so it would be painfully slow to use. Beside that, using swap also quickly wear out your SD card.
Sd-ext partition can be configured to accommodate swap, if you have the right app/script. Normally, you divide your SD card in to 3 partitions, 1st for media, 2nd for app storage, 3rd for swap. And our phone's recovery have option to do this too.
As I said, I strongly object against using swap partition. It will make your phone even slower than without it.
Your best bet here is zRAM, or compcache. You can find zRAM setting in most CM based ROM. zRAM relies on compression to increase the virtual size of your RAM. For example, an app that usually takes 10MB of RAM will now take only 9MB if you choose 10% compression.
There're 10%, 18%, and 26% options. But zRAM is not free. It uses your CPU to compress and decompress data, so our phone's weak CPU is not very happy with it. Your choice. But if you really need more app to cache more app (better multi-tasking), 10% zRAM will give you about 40MB RAM more (400MB*10%=40MB), at the cost of little CPU and battery. Using 18% and 26% seems too aggressive.
redguardsoldier said:
No, you can't. Physical RAM is fixed.
Swap acts as pagefile on Windows, if you know pagefile. swap is virtual RAM. When the system needs more memory, a part of RAM will be written to the swap partition. Swap partition is part of SD card, so it would be painfully slow to use. Beside that, using swap also quickly wear out your SD card.
Sd-ext partition can be configured to accommodate swap, if you have the right app/script. Normally, you divide your SD card in to 3 partitions, 1st for media, 2nd for app storage, 3rd for swap. And our phone's recovery have option to do this too.
As I said, I strongly object against using swap partition. It will make your phone even slower than without it.
Your best bet here is zRAM, or compcache. You can find zRAM setting in most CM based ROM. zRAM relies on compression to increase the virtual size of your RAM. For example, an app that usually takes 10MB of RAM will now take only 9MB if you choose 10% compression.
There're 10%, 18%, and 26% options. But zRAM is not free. It uses your CPU to compress and decompress data, so our phone's weak CPU is not very happy with it. Your choice. But if you really need more app to cache more app (better multi-tasking), 10% zRAM will give you about 40MB RAM more (400MB*10%=40MB), at the cost of little CPU and battery. Using 18% and 26% seems too aggressive.
Click to expand...
Click to collapse
Does zRAM works without swap partition ??
Yes, it's different, you can read @redguardsoldier's post again, to get exactly what he is saying, just to be on the safe side
Increase RAM In HTC Pico (I worked For ME ).
ahmadmemon said:
I wanted to know if we can increase the ram of our little pico (htc Explorer)....also I wanted to know the advantages of swap partition.....Does it increase the ram size ?? And also I wanted to know that if there are any other advantages of Sd-ext partition other than increasing the Internal memory ??
Click to expand...
Click to collapse
TRY THE LINK BELOW IT WOKED FOR ME :laugh: >>>>>>>>>>>>
http://forum.xda-developers.com/showthread.php?t=2735281
I hope It will work for u as WELL :good:
Hi all,
With this Xiaomi device SoC source code was never released so only stock kernel can be used. Is it possible to turn on ZRAM and change ZRAM values with it still if I was to gain root?
Many thanks
LaurenceGough said:
Hi all,
With this Xiaomi device SoC source code was never released so only stock kernel can be used. Is it possible to turn on ZRAM and change ZRAM values with it still if I was to gain root?
Many thanks
Click to expand...
Click to collapse
You already have zRAM enabled by default. AFAIK modern Android devices don't use a swap partition (except RAM+ features).
see your zRAM:
Code:
su
cat /proc/swaps
adjust your zRAM:
Code:
su
swapon --help
the size of your zRAM is defined in
/vendor/etc/*fstab*
WoKoschekk said:
You already have zRAM enabled by default. AFAIK modern Android devices don't use a swap partition (except RAM+ features).
see your zRAM:
Code:
su
cat /proc/swaps
adjust your zRAM:
Code:
su
swapon --help
the size of your zRAM is defined in
/vendor/etc/*fstab*
Click to expand...
Click to collapse
Thanks very much, that command is super useful and no amount of Googling I did could find it!
/vendor/etc/*fstab* reports:
"/dev/block/zram0 none swap defaults zramsize=55%"
This sounds like ZRAM should be enabled at 2.2GB.
The problem with this device is the swap partition is reported as always 2252MB, yet even with the "RAM" boost turned on or off the "swap" partition is reported as the exact same size. I suspected based on the really, really poor memory related performance it is disk based SWAP... Anything more than 2-3 simple apps and they reload constantly like they were fully closed when switching apps. All power saving features are turned off.
P.S I am not rooted just yet, I was just trying to see if I could improve my performance as the CPU is quite strong but memory is the issue.
Thanks again
Edit:
I just ran /vendor/etc/*fstab* again after enabling "RAM boost" and restarting, it says it's on in the app switch view (+2GB) but the output is the exact same of this file, I am not sure if this is to be expected or not. Performance is exactly the same so I guess it's just another MIUI bug?
This "SWAP" partition is also not always full usually only 1GB out of the 2GB in use. Checking against a Pixel 7, it's 3GB of ZRAM (reported as SWAP, but of course no RAM boost or SWAP exists on Pixels) it's fully utilized almost always despite having double the physical RAM.
LaurenceGough said:
at 2.2GB
Click to expand...
Click to collapse
LaurenceGough said:
always 2252MB
Click to expand...
Click to collapse
we calculate with base 2!
=> 1024^2 = MiB = 1.048.576 Byte
=> 1.048.576 x 2258 = 2.367.684.608 Byte = 2,2GiB!!
=> 2258MiB = 2,2GiB
There is no partition or used storage for zRAM/swap on your device. Consider that zRAM is compressed with lz4 (=50% compression). So, 1GiB RAM storage needs only 512MiB zRAM storage. The (de)compression is done by the kernel.
zRAM (and also swap) can't boost your system. These partitions are only used for cached data. Before your kernel deletes this data to clear RAM storage it gets compressd and stored in the zRAM area. It's the most useless data.
zRAM is a dynamic partition on your RAM. If RAM only needs 128MiB zRAM then zRAM won't be greater than 128MiB. It never increases to the full available size until it's really needed. If fsrab states "55%" than 55% is the maximum size of zRAM in your RAM and not a persistent size that is always occupied.
Don't change anything regarding to the RAM management as Android is nearly perfect handling thas by itself. You can only make it worse.
Thanks again. The issue I'm facing is that just a few basic apps struggle to run when multitasking, I have disabled all power saving features and MIUI optimisations / powerkeeper daemon but when switching apps or webpages they very often reload fully. I am certain this is an issue with low memory, and I know 4GB is not a lot of memory these days, but I thought I could run more than two tabs in a web browser, and more than a few simple apps without them reloading.
My understanding of zRAM is that it compresses RAM as you say, whilst this taxes the CPU more it should be able to compress more data into the RAM, effectively allowing more apps / webpages (pages) to stay available to use, rather than being killed by the low memory killer dameon lmkd.
Is my understanding correct that this 55% zRAM would provide an extra ~3.3GB or so of compressed RAM, making the total addressable RAM approx ~5.3GB?
If the 2GB of "RAM boost" or SWAP as it should be called if I am correct was working I'd expect it to be able to keep a few more apps or tabs running in memory and prevent a full reload? Is there any way I could check if this is running correctly without root? I know SWAP partitions are not ideal and they have a few downsides but I think this phone has relatively fast storage for its price range.
I am on the lookout for a device with more RAM but it'd be nice to understand a bit more about this situation and learn.
LaurenceGough said:
making the total addressable RAM approx ~5.3GB?
Click to expand...
Click to collapse
Your RAM storage remains 4096MiB. The swapped data in zRAM is compressed and can't processed until it gets decompressed. All data in zRAM actually should have been deleted and this storage isn't acting as additional RAM storage increasing your performance per se.
Apart from that Android's RAM management always uses 60-70% under normal conditions. For peaks, due to some heavy memory using apps, it can increase to 80-90% while at the same time zRAM increases, too. It's correlating. You can't force RAM to swap everthing into zRAM for having 2-3GB available. That's not the meaning of zRAM.