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.
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 don't seem to understand that why do the sIII has too less free ram, it doesn't have HTC sense either, but so what's the problem
Comparison on normal basis:
Free Ram on:
-HTC explorer = 240
-SIII = 340
-Optimus one = 330
Q1
Can someone tell me what app or the list of useless apps that are ram hungry?
Q2
Why do all devices have less ram example, Optimus one has 512 mb ram and available 421 with cm9
S3 has 1Gb and available around 760
Why, and if it is system reserved then why do we see system apps in taskillers
Press the "Thanks" button below if I've helped.
Free RAM is wasted RAM in Android.
Sent from my GT-I9300 using xda app-developers app
S3 has 1Gb and available around 760
Click to expand...
Click to collapse
'free' shows 778MB after conversion from KB to MB (1MB = 1024KB)
That 1GB includes hardware-reserved locations suche as for the GPU which, unlike mid- to high-end desktop computers has no real dedicated memory. Additionally there are the camera app (especially video encoding is notoriously high on RAM due to the codec specifications), the modem, ...
I'm also not sure if that 1GB is, as hardware manufacturers often tend to do, 1'000'000'000 Byte (1 GB according to hardware manufacturer'sIEC definition) or 1073741824 Byte (as defined by SI and adopted by software manufacturers)
That would reduce the capacity by a further 7.37% on RAW storage.
why do we see system apps in taskillers
Click to expand...
Click to collapse
You shouldn't be using Task Killers. I still remember them being a de-facto requirement in Eclair, but since Froyo they are obsolete and cause more harm than they can do good.
(At least in theory, memory management only recently with ICS got reliable and performant enough to completely get rid of them)
ijeff said:
Free RAM is wasted RAM in Android.
Sent from my GT-I9300 using xda app-developers app
Click to expand...
Click to collapse
If you have very less free ram your phone will start lagging and your phone will become a waste phone. Is that alright for you?
Press the "Thanks" button below if I've helped.
d4fseeker said:
'free' shows 778MB after conversion from KB to MB (1MB = 1024KB)
That 1GB includes hardware-reserved locations suche as for the GPU which, unlike mid- to high-end desktop computers has no real dedicated memory. Additionally there are the camera app (especially video encoding is notoriously high on RAM due to the codec specifications), the modem, ...
I'm also not sure if that 1GB is, as hardware manufacturers often tend to do, 1'000'000'000 Byte (1 GB according to hardware manufacturer'sIEC definition) or 1073741824 Byte (as defined by SI and adopted by software manufacturers)
That would reduce the capacity by a further 7.37% on RAW storage.
You shouldn't be using Task Killers. I still remember them being a de-facto requirement in Eclair, but since Froyo they are obsolete and cause more harm than they can do good.
(At least in theory, memory management only recently with ICS got reliable and performant enough to completely get rid of them)
Click to expand...
Click to collapse
By the way what thing takes up so much ram
HTC phones has memory hungry sense so it's understood but what's the problem here?
Press the "Thanks" button below if I've helped.
rishabho1 said:
By the way what thing takes up so much ram
HTC phones has memory hungry sense so it's understood but what's the problem here?
Press the "Thanks" button below if I've helped.
Click to expand...
Click to collapse
Touchwiz is by far more memory hungry than sense.
joshnichols189 said:
Touchwiz is by far more memory hungry than sense.
Click to expand...
Click to collapse
I see
But touchwiz has nothing special, and no flipping clock no cool widgets and no sense like cool launcher
Press the "Thanks" button below if I've helped.
haha there is far more to Sense and Touchwiz than just a few widgets dude!
By the way what thing takes up so much ra
Click to expand...
Click to collapse
Get houmiak Task Manager from Market and look for yourself. Many useful features are completely unnecessary for most of us, so you can freeze them to gain memory. (Don't uninstall since you can defrost frozen apps instantly if you ever needed it)
Those included for me the Exchange service, Allshare, ... . There's a whole list of apps which are safe to remove.
(Note that 'safe to remove' does not mean you won't need it: that depends on what you actually use)
But touchwiz has nothing special, and no flipping clock no cool widgets and no sense like cool launcher
Click to expand...
Click to collapse
Both Touchwiz and Sense are horrors in terms of coding standards and resource consumption. If all you care about in Touchwiz is the launcher and widgets then by all means get rid of Touchwiz (I recommend CM9) and install a customizable Launcher such as Go Launcher, Apex, ...
If you have very less free ram your phone will start lagging and your phone will become a waste phone.
Click to expand...
Click to collapse
"Free" memory is a very interesting defition. What do you call 'free' memory?
If an app is closed, should Android immediatly remove it from Cache? You'll probably say yes to increase free memory.
However there are multiple reasons why it's not done
- free memory is wasted memory. If the phone doesn't use it, what's the point of having it?
- it doesn't cost anything in terms of CPU-cycles to "remove" cached apps from RAM whenever the space is needed [*]
- Should you multitask back in the app, it's immediatly available. Depending on the app, even with everything exactly as you left it
[*] Well it does, but not more than immediatly removing it when the app is closed.
If you work a lot within the same app, chances are that your free memory is far below 1MB since it keeps everything in Cache if it should ever be needed. By exiting or killing an app that value increases since some data is always freed. But that does not mean the phone will magically get faster. If you still don't believe me; what if I told you that there is NO major operating system (Mac OsX, Windows NT, iOS, Linux, BSD, ...) that does not cache. You just don't see the raw values Linux shows on most of them, but faked values where the cache is substracted.
If you want details, I recommend reading about Paging ("Swap") and In-Memory Caching on Wikipedia. They have some excellent articles.
Here's a shortened easy versioN: http://www.linuxatemyram.com/
rishabho1 said:
If you have very less free ram your phone will start lagging and your phone will become a waste phone. Is that alright for you?
Press the "Thanks" button below if I've helped.
Click to expand...
Click to collapse
My phone never lags. Sometimes there is a brief delay when a screen redraws upon app change. I hardly think the phone becomes a "waste" at this point. If you want to see what lag really feels like go get a second hand HTC desire.
Sent from my GT-I9300 using Tapatalk 2
It is sad that the available ram is less than on the S2 to be honest.
I'm running with 80-200mb free all the time, even been down to around 50mb when using the phone, the S2 I was never under 150mb.
But then again, the S3 is faster than the S2
extreme unstable ram usage
hawkn said:
It is sad that the available ram is less than on the S2 to be honest.
I'm running with 80-200mb free all the time, even been down to around 50mb when using the phone, the S2 I was never under 150mb.
But then again, the S3 is faster than the S2
Click to expand...
Click to collapse
wow, you lucky s3 fellow, i have been experiencing ram issues, when I say that, know that I have considered the fact that more RAM used the better - more apps in memory, improves app switching/launching speed(all that philosophical BS which people give with pride, when someone posts a query on RAM. My RAM exceeds 700 MB and goes up to 796 MB with less than 50 MB at times; and this is with 10-15 trusted lightweight apps installed, This was prevalent since the stock firmware ICS and even is present after the JB update. More RAM used is good only when it doesn't affect performance, and doesn't force apps to struggling to stay in memory, causing them to frequently restart.
though i found a partial fix, which gave a lil speed boost -> http://forum.xda-developers.com/showthread.php?t=1787263&highlight=ram+problem
This helped me a lil(Disabling ripple effect in lockscreen), though to totally resolve the issue, i might have to go for a custom rom/kernel or hope for sammy boys to release an update soon -> http://forum.xda-developers.com/showthread.php?t=1926380&page=3
I've been quietly lurking on this site for about 2 weeks since I got a nook tablet (16GB) with an N2A card (which was horrible). I came to this site looking for a way to mod my device and ended up learning a lot more than I intended. I have sampled quite a few ROMs on here and am astonished at the amount of work that has gone into these ports. I have a device that is so much more functional it's not even funny. Already I've reclaimed the space that BN had partitioned from users. I still have a lot to learn but I wanted to express my thanks to all the developers who work hard on these. I am very appreciative that a device which is technically 'obsolete' can be revitalized and turned into something very usable. I am still trying out various ROMs to try to see which is giving me the best stability and RAM use. So far the one I am using I unfortunately forgot the name of. Any way of finding out which ROM you might have flashed? What I like about it is most of the ROMs use so much RAM I am left with around 200MB of RAM without anything running. One particular ROM I'm using consistently gives me around 400-450 MB of free RAM even with some background apps running. A HUGE improvement. A couple ROMS literally left me with less than 100MB. Anyway if anyone has any advice or happens to know how to determine which ROM I might be using I'd be very happy. Mainly I wanted to introduce myself and thank the developers. GREAT STUFF!
Some info that most Android users are not aware of, as its a bit non-intuitive:
Having less memory (RAM) available is actually a good thing. Apps can be "running" in the background without actually using the processor or other resources. They are cached via the RAM in order to allow you to relaunch them quickly. Android's memory management is quite good, albeit different from say Windows.
This is why Task Killers are generally a bad idea. I used to use them as a means to kill apps when they froze or whatever, but now, with the roms I have on my devices, I have set long-press of the back button to kill the current app, should I need to do this.
Read this article for a bit more info.
tl;dr less memory available is not necessarily a bad thing on Android.
Sorry for delayed reply
Forgive my tardy response. Our internet was out for 2 days. I understand what you are saying but what I was noticing was a huge number of active programs that were not in use, nor are commonly in use enough to justify their being cached. One particular ROM was leaving me with less than 200 MB of RAM with the same processes referred to above being inactive as well. A 200MB difference with the same stuff running. The particular one I'm on now keeps a number of things running in the background and still leaves me with well over 300MB with 4-5 programs going at the same time. So while I agree with you that some might be doing more cache than others, my experience is telling me the build with the most RAM (ie whichever one I am using...I unfortunately forgot which I installed...a CM10 but not sure if it was the cherry pick or chris'.) is the one that is managing the memory the best. I can figure out no other explanation for the same number of programs using an extra 200 MB of memory over another rom and thinking that is a good thing. For example, the ones I am thinking of are running stuff in the background I don't even use. Power Amp is a huge offender for whatever reason. I see no reason to have it running 24/7 but it does!
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.