Database Info

Question regard the total amount of RAM in a ROM

To all the ROM cooks and expert,
I have a quick question regard the TOTAL amount of the RAM available in a ROM. I tried many new and old roms in this forum and I found one general conclusion. That is generally for all the roms (except the one with UL, Throttle Laucher, or SPB shell loaded), the amount of used RAM after a reboot is about the same, about 23 ~ 24 MB. However, what make the amount of free RAM available depends on the amount of TOTAL available RAM. This is my question, how come in some roms, there is about 52 MB available while some only have about 47 MB available. As you can see, the difference is about 5 MB, which is a good amount? Thanks

The total available RAM has to do with how big the pagepool is, how much is dedicated to the kernel, etc. The free RAM has to do with what's running in the background (programs, services, etc.)

ivanmmj said:
The total available RAM has to do with how big the pagepool is, how much is dedicated to the kernel, etc. The free RAM has to do with what's running in the background (programs, services, etc.)
Click to expand...
Click to collapse
I know to get more free ram, we can disable startup services and some background programs, but can we get more TOTAL available ram? I should ask this question up front. Our device, Herald or Wing, have 64 Meg of RAM, even with your JUSTME, the maximum it shows in "Device Information" is about 52 Megs. Where is the remain 12 Megs go? Can you tell me more details about it. Thanks

live4nothing said:
I know to get more free ram, we can disable startup services and some background programs, but can we get more TOTAL available ram? I should ask this question up front. Our device, Herald or Wing, have 64 Meg of RAM, even with your JUSTME, the maximum it shows in "Device Information" is about 52 Megs. Where is the remain 12 Megs go? Can you tell me more details about it. Thanks
Click to expand...
Click to collapse
I would think it would be for the OS software but I could be wrong.

speoples20 said:
I would think it would be for the OS software but I could be wrong.
Click to expand...
Click to collapse
Thanks. If it is for the software, then it should reside in the ROM. RAM is for anything that is running, currently or background. What I don't understand is that papa's newest RC6, Open Touch 6.5, and PDA viet's most updated ROMs they all have the same OS build (at least I believe they are), but the TOTAL available ram is different on each ROM. I am trying to build my own rom and just try to learn many thing as possible. Thanks

The "missing" RAM is taken by the XIP (kernel and such) and various other things like the pagepool. If these guys ran from the ROM, the device would be extremely slow.

Filesys.exe uses too much RAM

Filesys.exe uses 16 of my 64mb of RAM on my wm6.1 device. Does anyone know how to reduce this (im using sktools to optimize mem but it doesnt help.)
Filesys modules:
flx_wm_av_dll.dll
coredll.dll.0409.mui
btp_btfsd.dll
ole32.dll
sqlcese30.sys.dll
msasn1.dll
crypt32.dll
rsaenh.dll
relfsd.dll
diskcache.dll
fsreplxfilt.dll
fatfsd.dll
cecompr.dll
fsdspy.dll
imgfs.dll
mspart.dll
smflash.dll
fsdmgr.dll
certmod.dll
coredll.dll
Thanks,
Will

Try decreasing the file system cache. I don't know if the glyph cache or the file filter cache will help or not, but you could also decrease them to find out. Still, 16 MB seems like a lot. I just checked my filesys.exe, and it's ~2MB (I have the cache at 2 MB for the helluvit, but frequently run it at 8 MB). You can decrease the file and glyph cache with sk tools, but you'll need to edit the registry or use advanced configuration to tweak the filter system cache (fsreplxfilt).
Do you have a bunch of over-written rom files? I think that might increase the ram usage of filesys.exe (not sure, just a guess); I've read that over-written files go into ram, but am not 100% sure on this. You should use sk tools to check for over-written rom files, and see if you have like around 14 MB worth of them (maybe for an updated net framework).
Edit: here's the reg setting for fsreplxfilt:
[HKEY_LOCAL_MACHINE\System\StorageManager\Filters\fsreplxfilt]
"ReplStoreCacheSize"=dword:00001000
My value is for 4096 sectors. I'm not sure that reducing the value from what you have will help, but it's worth looking into.

After doing what you said, I was able to reduce the size to 14mb. Anything else I could try?

I'm all out of ideas at this point. How are you getting the reading of 14 MB-which task manager are you using? When I used dotFred's task manager, I see that ~2 MB are being used. But with SK Tools, I see the size is ~10 MB, and the heap size is around 5 MB. I think they have a different way of calculating the ram usage, and SK may be including virtual memory alotments into the sum. Check this article for more on VM, but I have a feeling you're ok. I don't really understand this stuff 100%, but here's a screen-cap of my VM alotments right now (each slot has 32 MB). The second slot is filesys.exe. You can see that most of the memory allocated on the bottom (where the heaps and source code is) is green-this is memory that has been committed to filesys.exe, but isn't actually being used. I suspect that SK Tools includes that in the 14 MB of usage (and maybe the dll's at the top), but a different task manager like dotFred's won't. I have no idea how you would go about lowering the commitment, or if it is possible at all. Try a different task manager and see how things look.
Edit: I switched my cache-size back to 8 MB-that may be all the green, but when I ran the virtualmemory.exe with a 2 MB cache, I seem to recall it looked about the same.
Ok, I went and estimated the size of the commitments in my filesys memory slot. On the bottom, the green (allocated but unused) is ~10 MB, and the blue (used) is ~2 MB. The total size is 12 MB (obviously), and the dll alotment at the top is ~4.7 MB. I guess that SK tools is listing the size as the 10 MB of unused but allocated VM. The 2 MB that is in use appears to be what dotFred's task manager reports. I'm not sure what's up with the heap size that sk tools reports (5 MB), but I guess it must include the blue and some of the green on the bottom. There's still ~15 MB of free virtual memory available in the slot. You run into memory errors when that number gets low (or it runs out), even if there is free ram. I don't believe that the green alotments actually use ram-this is just reserved virtual memory. I also am not sure how you spell alotment-I decided to go with on 't,' lol.
If you read the help section for the sk tools task manager (processes), it says "the utility displays the amount of memory used by the process. In Settings, you can select to display used dynamic memory as well. (Some programs display used dynamic memory as total used memory amount; this is incorrect, and may lead to confusion.)" I think this is clearly where the confusion lies. I'm not sure what they're talking about in Settings, though-all I see is the choice to display the heap size-I guess this is the used dynamic memory, as they call it. I'm not sure why it doesn't jive with what dotFred's displays. I guess it's just bean counting in the end, and there's different ways to add things up.

DotFreds TM says about 14mb - just like sktools. Is 25 mb free mem after boot acceptable for a 64mb pda? It was never much better, even with m2d uninstalled.

Yes. I have a P3400 with 64 mb RAM too and I get 22-25 free ram at startup and 18-20 free after some usage.

288 MB ram? but where to find it?

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.

[CompCache] Setting compcache to full RAM size

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

[Q] Free RAM

Hi people!
I'm investigating how to reach maximum performance with Android in my POLA200.
I had run top command from the terminal emulator and I note that I have only 1 MB ~ 3 MB of free ram.
My questions are:
- How can we free more ram?
- Installing it in NAND gives us more free RAM? (I think not but not sure 100%)
The more free RAM we can get, the more performance we can get in running apps (no swap)
I'm running VaniljEclair RLS11. What happens in Warm Donut or in Froyo if you run top?
How much RAM have you got?
Thanks in advance. This will be a nice thread to get conclusions.

Too less free RAM you got there. If that bothers you much, try Warm Donut, or if you are really scrapping the bottom of the ship barrel for RAM, try Fresh Froyo or a Cupcake (1.5) build. But I will warn you, Cupcake is outdated.

Hi,
Maybe you can try to enable compcache ?
If you want you have to do that with an emulator (better terminal Emulator for example) :
type "su" and after type "compcache.sh start"
Wait a few minutes
after type "free" to see a new line called "swap".
With a Polaris100 I can see :
- Mem : 104008 (101868 used)
- Swap : 26000 (2732 used)
- Total : 13008 (104600 used)
Cheers.

I have it enabled. From spare parts-> enable compcache.
Running free after i see swap but it have 0 used.
Thanks!