Related
Hello guys
I already used the search and looked around on the internet using google and ecosia... but it didn't help me... everytime i am looking for the answer to my question: "HTC says that the touch pro has got 288 MB of ram but there are only displayed 193 MB and my free memory is about 65 MB (used 128MB)" i only find some roms that say that they have a lower pagepool... but that does not help me in finding a solution to my problem that i can't access the complete ram...
is there any workaround for this issue? a classmate found a rom for his touch hd2 which solved the same problem as mine but on his hd 2... now i ask you for a solution on the touch pro.. please help me ^^
i think you didnt think about the fact that the OS needs ram too ... but you can try ROMs without manila that spare ram; which ROM do you actually have?
I'm using the latest energy rom, its all fast and very smooth animations.. really great :]
but no i think you didn't understand me... the hardware ram is 288MB according to HTC. The memory manager shows me that there is in total only 193 MB available. 128 MB of these 193 MB are used... the rest is unsused memory... now what is about the rest of the 288 MB ?
the osram usage is included in the 128MB if you trust the task manager ^^
so what is my phones problem? are there maybe some limitations that can be solved with some registry changes? on windows vor PCs you can disable some parts of the ram that they are not used... can this be a possible problem on my phone? when I was using the O2 branded original rom there were 212 MB usable 80MB used and 132MB free... i really can't imagine why ._.
ok, i see, but what about the memory that is needed to store the files that will be used restore the files after you do a hardreset?
Do you know nue storage manager? Try it and look, how much drives you have installed in your memory... which you dont have in normal use
do you know the difference between ram and rom? operating systems are always installed on roms and the ram looses its data during a hard reset.
audiocore said:
the hardware ram is 288MB according to HTC. The memory manager shows me that there is in total only 193 MB available. 128 MB of these 193 MB are used... the rest is unsused memory... now what is about the rest of the 288 MB ?
Click to expand...
Click to collapse
Yes, hardware RAM is 288 MB. In your case (with Energy ROM) 95 MB of RAM is used by the OS itself, so you have only 193 MB RAM available. You should know that the rest (in your case 193 MB) depends on the ROM cooker. Energy ROMs are known for not being RAM friendly, actually NRGZ28 stated once that he doesn't care for free RAM. That is the reason you have only 65 MB of free RAM. For example I'm using CRACING ROM and I have about 110 MB of free RAM after reboot, if Sense 2.1 is enabled. If I disable it, I have about 130 MB left. When I was using offical HTC ROM, I had more than 150 MB of RAM - that is with all today plugins (TF3D for example) turned off. Of course, if I disable HTC dialer (that has a video dialer and other options) and switch to ordinary WM dialer, I can free even more RAM. Pagepool is also very important - it is a special area of memory reserved for loading apps into from ROM. I think that the default pagepool is for Raphael 12 MB (that means 12 MB less RAM), but most of the cooks sets pagepool to 20 MB or more - that means 20+ MB of RAM used for faster loading of apps. That is why your phone is so fast with Energy ROM - it has a veeery large pagepool, but you have very little free RAM because of that.
So, to make things simpler, most of the RAM is used by the OS, GPU, TF3D/Sense/Titanium/SPB Mobile Shell/some other UI app, pagepool, dialer, other background services/processes etc. So you just have to decide what ROM to use - there are some ROMs (like yours current) that are very bad for RAM, but there are others with 120 MB+ or even 150+. You can also cook your own ROM and maybe gain 180 or more free RAM.
pilgrim011 said:
Yes, hardware RAM is 288 MB. In your case (with Energy ROM) 95 MB of RAM is used by the OS itself, so you have only 193 MB RAM available. You should know that the rest (in your case 193 MB) depends on the ROM cooker. Energy ROMs are known for not being RAM friendly, actually NRGZ28 stated once that he doesn't care for free RAM. That is the reason you have only 65 MB of free RAM. For example I'm using CRACING ROM and I have about 110 MB of free RAM after reboot, if Sense 2.1 is enabled. If I disable it, I have about 130 MB left. When I was using offical HTC ROM, I had more than 150 MB of RAM - that is with all today plugins (TF3D for example) turned off. Of course, if I disable HTC dialer (that has a video dialer and other options) and switch to ordinary WM dialer, I can free even more RAM. Pagepool is also very important - it is a special area of memory reserved for loading apps into from ROM. I think that the default pagepool is for Raphael 12 MB (that means 12 MB less RAM), but most of the cooks sets pagepool to 20 MB or more - that means 20+ MB of RAM used for faster loading of apps. That is why your phone is so fast with Energy ROM - it has a veeery large pagepool, but you have very little free RAM because of that.
So, to make things simpler, most of the RAM is used by the OS, GPU, TF3D/Sense/Titanium/SPB Mobile Shell/some other UI app, pagepool, dialer, other background services/processes etc. So you just have to decide what ROM to use - there are some ROMs (like yours current) that are very bad for RAM, but there are others with 120 MB+ or even 150+. You can also cook your own ROM and maybe gain 180 or more free RAM.
Click to expand...
Click to collapse
Great comment! Don't forget that the Radio will also use up some memory and especially with the HD2 there seems to be a Radio (original t-mobile) which uses almost 12 MB less than others.
However, what is your problem? You are concerned about battery life (keeping all that RAM happy and addressed) or you have a specific application which wont run. I didn't check the latest NRG ROMs but he ran pagepools up to 26 MB. It's one of the first things I check with a tool called pagepool changer. I adjust mine to 16 meg which is/was supposed to be the sweet spot for the Raphael/TouchPro and never had any problems, speed or memory issues.
tyguy said:
However, what is your problem? You are concerned about battery life (keeping all that RAM happy and addressed) or you have a specific application which wont run.
Click to expand...
Click to collapse
If the question is adressed to me, and not OP, I need at least 90-100 MB of free RAM because I heavily multitask. That is the main reason for being WinMo user. Besides, ROMs with low RAM are usually battery hungry.
pilgrim011 said:
If the question is adressed to me, and not OP, I need at least 90-100 MB of free RAM because I heavily multitask. That is the main reason for being WinMo user. Besides, ROMs with low RAM are usually battery hungry.
Click to expand...
Click to collapse
My answer was addressed to both. I also multitask though mainly Word, Excel and chat and as long as I don't open iGO all is running well (and you don't multitask while driving anyway ).
Let me check how much free RAM I have. ROM is in my sig, modified the PP from 26 MB (NRG's default) to 18 MB, Manila 2.5 with added Program Tab and Max Manila 2.7SE fullscreen on top. As you see I run the xperia X2 task manager because I too like to know what's left in RAM.
The screenshot is after ~ 4 days after the last boot "active sync'd"
tyguy said:
I also multitask though mainly Word, Excel and chat and as long as I don't open iGO all is running well (and you don't multitask while driving anyway ).
Click to expand...
Click to collapse
Well, I do multitask while driving. For example, iGo is running along with browser. When I need informations about traffic on main intersections (from the video cameras in my city), I open the link for that particular intersection via browser and then Streaming Media plays that clip. In the meantime iGo is running in the background of course. Lot of RAM is required for these tasks. And what if someone calls me - the dialer is also RAM hungry... Besides, often I use GPS whilst walking. This is just an example - like I said, I'm a heavy multitasker.
humm okaaay... but on my older eten glofiish x650 with only 64MB of ram I had about 24MB of free ram though windows mobile 6.5 (only tried it out ) so windows mobile can be 40MB small... and although it seems to run very well...
humm what do you mean with radio? the music radio or something like gsm radio module for windows mobile? (sry 4 my comprehension issues but i'm from germany ^^)
talking about the radio rom, which can be updated / changed like the OS and make it possible to get better phone reception or gps or ...
audiocore said:
humm okaaay... but on my older eten glofiish x650 with only 64MB of ram I had about 24MB of free ram though windows mobile 6.5 (only tried it out ) so windows mobile can be 40MB small... and although it seems to run very well...
humm what do you mean with radio? the music radio or something like gsm radio module for windows mobile? (sry 4 my comprehension issues but i'm from germany ^^)
Click to expand...
Click to collapse
I really think that you should read XDA Wiki, as much as humanly possible, in order to understand basic things about WinMo. Cheers, mate.
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
Hi! I try xdandroid rom from his official site.
Apart little things maybe fixed on other rom that i've found here, there's a method to increase the available RAM? Because I've a Raph100 and it use only 50/60 Mb (I saw that in the "running applications" menu).
Thanks!
TheXeno said:
Hi! I try xdandroid rom from his official site.
Apart little things maybe fixed on other rom that i've found here, there's a method to increase the available RAM? Because I've a Raph100 and it use only 50/60 Mb (I saw that in the "running applications" menu).
Thanks!
Click to expand...
Click to collapse
Well obviously to physically get more RAM you'd have to get the soldering iron out and be pretty brave.
To manage memory better, read my Speed Improvements thread. There's a topic that covers memory management - you can get as detailed as you want with it, or just use the SuperCharger script. Either way, depends on how much you want to learn it .
I don't understand very well, but i don't think this will change the physical ram used. I mean, if it runs under/with win mobile, maybe we can change one parameter to release more memory. Like the page pool setting: maybe applying this directly to haret.exe
But the problem is, winmo is shutdown completely; if I'm not mistaken. You know, the whole reason why you have to reboot your phone in order to get winmo back. Usually apps that run under winmo, you just shut down and either run cleanRAM to regain the memory or you could reboot at that time but you do it while winmo is still running in either case.
TheXeno said:
I don't understand very well, but i don't think this will change the physical ram used. I mean, if it runs under/with win mobile, maybe we can change one parameter to release more memory. Like the page pool setting: maybe applying this directly to haret.exe
Click to expand...
Click to collapse
You don't understand, WinMo is completely kicked out of memory - no trace of it is left. Many have done extensive tests, WinMo ROM speed has no effect on Android speed - why would it? It's not running "under" WinMo. HaRET is not a 'virtual machine' or an emulator. We're actually running Linux on the hardware - about all WinMo does for us is initialize said hardware.
Understand. And ok... but the question remains: my raph has 288Mb of RAM. Why Android use only 60? (in application menu: (plus or minus) "xx Mb used of 60 total")
TheXeno said:
Understand. And ok... but the question remains: my raph has 288Mb of RAM. Why Android use only 60? (in application menu: (plus or minus) "xx Mb used of 60 total")
Click to expand...
Click to collapse
Well 288mb is the total amount. In WinMo, you don't have that much total because of various things like video etc. Lots are beyond me.
Perhaps RAPH doesn't have all the banks available? I doubt it. Have you checked with free? In the terminal.
My RHOD says 171mb total, when I also have 288mb physically. I would think it would show more than 60 tho... Perhaps you've done something wrong? Using the wrong startup perhaps...?
You say you have a RAPH100, that isn't one of the crippled models.
So it's not only my diam100 who can not use all the RAM! I'm relieved!
I knew that even with 192MB, 64MB were blocked for VRAM (I think)
Winmo 6.5 shows a total of 111.66Mb
In settings, xdandroid 2.3.7 (compiled by me) shows only 30Mb, with free 0Mb
using the command FREE in the ADB, however, shows a total of 103Mb, with 1 or 2 MB free
In these days I'm doing some tests with compcache off, 24Mb (1 / 4 of RAM) or more
using Compcache the maximum memory is increased, but free is always 1 or 2Mb!
In the next days I will try with FRX07.1, we will see
Fabiett83 said:
So it's not only my diam100 who can not use all the RAM! I'm relieved!
I knew that even with 192MB, 64MB were blocked for VRAM (I think)
Winmo 6.5 shows a total of 111.66Mb
In settings, xdandroid 2.3.7 (compiled by me) shows only 30Mb, with free 0Mb
using the command FREE in the ADB, however, shows a total of 103Mb, with 1 or 2 MB free
In these days I'm doing some tests with compcache off, 24Mb (1 / 4 of RAM) or more
using Compcache the maximum memory is increased, but free is always 1 or 2Mb!
In the next days I will try with FRX07.1, we will see
Click to expand...
Click to collapse
Based on free, that sound accurate. Settings -> About Phone might be using some different metrics (I honestly don't know).
And what about the 1 or 2 Mb free? they're too less to be ALWAYS 2 Mb, or not?
TheXeno said:
And what about the 1 or 2 Mb free? they're too less to be ALWAYS 2 Mb, or not?
Click to expand...
Click to collapse
What is this, I don't even...
I mean that it isn't normal which there are always 2Mb free, in according to Fabiett83 (he says this)
I'm sorry, before i meant 1-2 mb of uncompressed ram, there was still free memory in compcache
I think android needs more than 100Mb of ram, so it keep closing open apps and processes when i/it need ram for anything else
this could explain the ever full ram and the long time needed for opening apps
even answering to calls needs more than a minute if the phone app is not open!
Edit:
This is the result of ADB Free command in a fresh FRX7.1 install
_____ ---- total --- used --- free - shared - buffers
Mem: -- 103160 - 101116 -- 2044 ------ 0 ----- 72
Swap: - 102392 -- 64004 - 38388
Total: - 205552 - 165120 - 40432
Android uses a total of 165Mb of ram
Now with compcache set to 80Mb in froyo.user.conf
_____ ---- total --- used --- free - shared - buffers
Mem: -- 103160 - 101332 -- 1828 ------ 0 ---- 256
Swap: -- 81912 -- 54032 - 27880
Total: - 185072 - 155364 - 29708
Here uses 155Mb, but leaves less compcache free
Last with compcache set to 64Mb
_____ ---- total --- used --- free - shared - buffers
Mem: -- 103160 - 101812 -- 1348 ------ 0 ---- 352
Swap: -- 65528 -- 34356 - 31172
Total: - 168688 - 136168 - 32520
I Don't know... seem to always use the max possible uncompressed ram and thel load the rest in compcache
what i can clearly see is that the less compcache i use the more responsive the system is!
I will stick to 64mb for a while, i hope 168Mb is enough for normal use
in my device htc one x mt6577 it have ram 1g but always used 802mb and free 186mb its high usage of ram and in same time i dont open any app and when i connect device to computer and run eclipse program this appear in this picture
in attachment
it appears 82% of ram uknown it need same to format it how i solve it please help me:crying:
From the SuperCharger OP...
RAM Lesson:
Important Note: FREE RAM IS NOT WASTED! - Read Linux Memory Consumption
...................... That article TOTALLY confirms what I've been saying!
To Summarize: Article: "Performance degradation occurs when "Absolute Free Memory" (includes Cached RAM) decreases."
...................... Me: "Lag happens when free ram goes below the 'lag level'"
Same thing, different language
Big Thanks to dev hardcore and this post for helping me figure stuff out way back when
Click to expand...
Click to collapse
Most tools/apps, when they report free ram, include cached apps and buffers and is much higher than what is truly free (which is what is shown by typing "free" in terminal emulator)
So, if something is telling you that you have high ram usage when "nothing is running", it may not be telling you what you think it's telling you lol
To see what's really going on, do in terminal:
free
or
cat /proc/meminfo
The following are two ram optimising scripts that actually do something. They will ensure a fluid experience by keeping a minimum of 100mb of ram free. Simple as that.
STEPS:
Download zip and extract files "boost" and "freeram".
On the tablet , use a root file manager
Paste files in /system/bin (system needs to be re-writable obviously)
Set permissions to rwxr--r--
Activate scripts manually after every boot using android terminal emulator:
1) free ram (to see ram usage)
2) su
3) freeram (no spaces)
4) boost
5) free ram (to see ram usage - compare to values in step1)
6) Profit
Explanation:
"boost" - activates Adrenaline Boost V3 (i take no credit for this script). What this does is clear the ram cache, freeing up ram storage.
"freeram" - a script i made, adjusts minfree values (android's built in ram manager) to kill off more empty apps from ram when ram usage exceeds certain values - not a task killer, so doesn't affect battery life
In android terminal emulator:
"su"
"cat /sys/module/lowmemorykiller/parameters/minfree"
-will show you the prior minfree values, "freeram" script adjusts these to 8192, 10240, 12288, 21000, 23000, 26000
Notes:
All changes reset on boot, so you'll need to to run everytime you reboot
check your ram usage before with: "free ram"
These two scripts will generally ensure about 300-400mb free ram always.
Removing widgets will improve this also.
If after a while nexus is feeling slow again, run "boost" script.
Fstrim or "lagfix" also helps with those having slow emmc issues
Enjoy more free ram
Or download an app called autokiller memory. Works miracles
mrazndead said:
Or download an app called autokiller memory. Works miracles
Click to expand...
Click to collapse
didn't know about that app.
This is more geeky and cleaner though, who doesn't want to use terminal??
And i don't think the app flushes the ram cache (similar to the adrenaline v3 script)
According to anandtech:
"I’m told that TRIM support has been part of the eMMC standard since around version 4.2, it was just a matter of enabling it in software. The result is that the new Nexus 7 shouldn’t have these aging affects at all. Better yet, fstrim support has also been added to the old Nexus 7 with as of the Android 4.3 update, so if you’ve got a Nexus 7 that feels slow, I/O performance should get better after fstrim runs in the background. I'm checking on whether the other Nexus devices have also had TRIM support added. I would consider the slow storage aging problem fixed as of now, and Google took the eMMC and storage I/O performance issues with the previous Nexus 7 to heart for this version."
Link: http://anandtech.com/show/7176/nexus-7-2013-mini-review/4
So that's good news for poorly ageing nexus 7's, just update to 4.3 instead of running lagfix
@mods: close/move the thread please.
this is another minfree / lowmemkiller script like Supercharger V6 which offers nothing more than actually less memory. What do I mean? It makes the device start killing apps/processes much sooner rendering it multitask-less. Provides a boost but at a terrible cost: much less mem available to apps...
I was able to multitask smoothly between 8 open apps without reloads. And I've been using this setup for 2mths or so.
I had memory issues with my n7, and this solved them, and I wanted to share as users (can't remember the thread name) were discussing slowness due to limited free ram, and this worked for me.
Mods feel free to close, sharing experiences is not appreciated obviously..
mpokwsths said:
@mods: close/move the thread please.
this is another minfree / lowmemkiller script like Supercharger V6 which offers nothing more than actually less memory. What do I mean? It makes the device start killing apps/processes much sooner rendering it multitask-less. Provides a boost but at a terrible cost: much less mem available to apps...
Click to expand...
Click to collapse
So basically, the Xda crowd is too dumb to make up their own minds?
Shouldn't it be up to the individual to try this (and any other) mod freely. Your personal experience with similar mods is welcome, but you trying to tell others what is best for them is way out of line imo.
IceColdJellied One X
Tapatalk 4 Beta
Shared knowledge = more knowledge imho
Thanks for sharing it! :beer:
On linux systems having a little amount of free ram is not necessarily a bad thing. it means that the apps you use most are available to be opened very quickly.
OP: what do you mean by "empty app"?
Appreciate your effort, OP. However, a more user-friendly way is to install an app like Rom Toolbox(and others) and change minfree. RT has presets, and set at boot features. I personally subscribe to the thought process that unused ram is wasted ram.
Nbsss said:
According to anandtech:
"I’m told that TRIM support has been part of the eMMC standard since around version 4.2, it was just a matter of enabling it in software. The result is that the new Nexus 7 shouldn’t have these aging affects at all. Better yet, fstrim support has also been added to the old Nexus 7 with as of the Android 4.3 update, so if you’ve got a Nexus 7 that feels slow, I/O performance should get better after fstrim runs in the background. I'm checking on whether the other Nexus devices have also had TRIM support added. I would consider the slow storage aging problem fixed as of now, and Google took the eMMC and storage I/O performance issues with the previous Nexus 7 to heart for this version."
Link: http://anandtech.com/show/7176/nexus-7-2013-mini-review/4
So that's good news for poorly ageing nexus 7's, just update to 4.3 instead of running lagfix
Click to expand...
Click to collapse
I wish My poorly aging Nexus 7 hasn't improved at all since the 4.3 update. In fact I think it's running even slower. I haven't run lagfix since the update though since I lost root and I'm waiting for Wug's updated toolkit to get it back. (I know I can restore root with other methods but I'm lazy and toolkits just make it easier.)
Aside from the TRIM issue I loved my old Nexus, but 16gb just wasn't enough space anymore and any time I dipped below 4gb of remaining storage it would lag so horribly I'd have to wipe the whole thing and start over if I wanted it to be buttery smooth again, even after using lagfix. Lagfix helped a bit, but it was still crawling compared to a freshly wiped tablet.
I've got a 2013 Nexus 7 on the way though so hopefully what you said about TRIM on the newer model is true and this one won't age as poorly as the original. Even if it does, having an extra 16gb of wiggle room can't hurt.
My thoughts
The most aggressive lvl on the minfree script is 26K ie 26,000*4/1024 = 101mb
Having less than 100mb of ram (ie over 90% ram used) slows down my n7 and its really bad when i have 19-45mb of ram left...
The fact that the script resets on reboot means i can easily compare the difference, for ME it helps and i can't notice an impact on multitasking (and thx for teaching me how to use terminal to check ram usage )
mrazndead said:
Or download an app called autokiller memory. Works miracles
Click to expand...
Click to collapse
Since i use this app my ram is always ok. Thanks so much, really improved a lot