Filesys.exe uses too much RAM - General Topics

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.

Related

RAM Program Utilization?

Can someone explain to me how Program Storage space is allocated.
To the best of my understanding the Kaiser has 128MB RAM for running programs.
However, if I look in the Memory applet it shows TOTAL 95.36MB. I will assume that this is calculating in the base RAM needed to load up the ROM?
So, if I have 95.36 TOTAL it then says I have 35.19 IN USE. This is after shutting down all running programs AND removing everything from the startup menu.
I then go into task manager to look at running tasks and add up all of their memory utilization and only get between 6-7MB. Now I don't totally understand because it looks like things like file system drivers and services are listed here...I would think those things would be included in loading the device itself (and this part of that missing RAM from the 128 as mentioned above).
So with only 6-7MB accounted for in Task manager, what is taking up the remainder of the 35.19MB?
Also, does anyone have any good stats on at what % utilization the device starts to slow down? Theoretically you should be able to run very close to maximum RAM (assuming all needed apps are open).
And, another question out of curiosity is what do most people have for their base utilized RAM on a clean reboot? By this I mean you would have all your services loaded (BT, voice command, touchflo, etc.) and all your necessary today plugins, menu shells etc, but NOT applications like PIE or TCPMP. I find that mine tends to be in the 60%+ range as of right now.
Thanks for any info you can give!
Ok.. I just realized that the Task Manager had additonal tabs that I didn't see...specifically services. Now on a WindowsXP system running services will also usually list a corresponding process that shows RAM utilization. WM doesn't seem to show that information.
So it's entirely possible that all my missing RAM is taken up by additional running services. Any application that will fully detail this out for me?
Also, is there a list of services somewhere? I often go into my XP machine and disable any extraneous services... can I do the same in WM?
thx
yes, and there is also the so called "page-pool' that is a sort of cache / buffer.
th_undead said:
yes, and there is also the so called "page-pool' that is a sort of cache / buffer.
Click to expand...
Click to collapse
this is true, the higher your page pull the less ram you will have but the faster your phone will run. i remember back on my wizard i would alway set like a 32(i think it was 32 or mayb 16)mb pagepool so the phone would run super fast. but at the same time i had like 15mb of free ram....i toke a faster phone lol
Ah right the pagepool... and I think dutty's latest uses a 24MB one which could account for alot of the missing RAM.
Ok...well so here is another question.
Let's say you are running at a high memory utilization....let's say 70-80%
If you could drop that down 10-15% by decreasing your pagepool would that be more efficient? This goes back to my original question of performance as utilization levels increase.
I thought I saw a post somewhere that showed only very minor increases in performance as the pagepool was increased... is it worth that vs. the slowdown (if any) when running at a high utilization?

High memory usage

When I tap the upper right button on my Touch PRO (system manager)
there is a memory usage stated in procent.
When I boot the phone it is at 40% and after a day or when I have
charged the phone, it is up at 50% whit no programs running.
My friend have the exact sampe phone, but his is at 30% when it has just
booted.
I think mine has pretty high memory usage, even though nothing is runnig.
What is normal and do you have a good way to tweak the memory usage.
I have tried oxios hibernate and it doest even work on Touch PRO.
Would want to hard reset. But do you think that is the only thing to do?
After a couple of days without booting, starting and closing apps like tomtom, msn messenger and opera, now only active sync running: 43% mem usage.
What I'd do if I were you; hard reset the phone. And install advanced config.
housert said:
After a couple of days without booting, starting and closing apps like tomtom, msn messenger and opera, now only active sync running: 43% mem usage.
What I'd do if I were you; hard reset the phone. And install advanced config.
Click to expand...
Click to collapse
Maybe the advance config is the problem Made pretty many tweaks...
Ill wait a few more post, to see if I can avoid the hard reset.
Hope to have a good tip on the memory usage...
delete the cashe and stored files in your internet browsers,such as IE and Opera...you will notice lot of difference
try using memmaid that will clear your temp files and also defrag and reclaim unsed ram.
Thanks for your tips.
None of them worked however
Ill have to hard reset I guess...
Did the reset.
Same problem after I have installed my apps.
Before the reset I tried to use "clear temp". The resault was that my mem-usage went down to 32%. Tought I would get an even better resault if I reseted the device.
Guess Im a sucker!
I have:
Klaxon alarm
Advance Config 3.2 (+netframe 3.5)
GSfinder+
tomtom7
SSMaPa (to have my clock open klaxon)
Also have iContact but had the memory problem before that.
I have done the tweaks to set:
File system cache to 8mb and file system filter cache to 131072
Fatfs Cachesize from 16384 to 32768
Do you see anything strange here which drain memory?
Really want to have the best possible preformance whit the official rom, and no memory draining programs.
File system cache to 8mb and file system filter cache to 131072
Fatfs Cachesize from 16384 to 32768
If i increase fatfs cachsize, tha system cache tweak is canceled..
I have to do it again in advance config, and then the fatfs is canceled. Creates kind of a bad cirkle.
Seams as this was party of the problem.
Now I have 35-40% but still 5% worse then my friends...
omg you think your memory usage was bad, mine is 74%
i have the following programs:
Google Maps
Advance Config 3.3 (+netframe 3.5)
pocket uno
touchflo 3D today
any suggestions??? i'm really stuck and need to get this down to 'normal'
You guys are lucky
I cannot get over 54% or something... then OS starts autokilling. I have disabled the HTC taskmanager autokilling and set memory threshold to very low but still no luck... I also made a hard reset and reinstalled all apps but still the same. I also put SKtools memory shadow service to autodefrag the ram and STILL ....
Using Advanced Config, change File system cache to 8mb and file system filter cache to 131072
HKLM\System\Storagemanager\Fatfs and change key Cachesize from 16384 to 32768
Disable any TF3D tabs you dont use.
If you dont use voice command prevent from opening up at start up by going to /windows/startup and deleting voicecommand.
Turn off voice command options in the setting menu.
Turn off accept all incoming beems in the settings menu.
Disable TTY in the serttings menu.
Ethania said:
File system cache to 8mb and file system filter cache to 131072
Fatfs Cachesize from 16384 to 32768
If i increase fatfs cachsize, tha system cache tweak is canceled..
I have to do it again in advance config, and then the fatfs is canceled. Creates kind of a bad cirkle.
Seams as this was party of the problem.
Now I have 35-40% but still 5% worse then my friends...
Click to expand...
Click to collapse
Just a thought that may help you. You see the increased cache sizes, "8MB" and "131072?" I had the same settings and I noticed the program memory usage got very high, stayed above 50%. Per my understanding, when you have that high cache sizes, you yourself give away some of the memory to the programs in terms of cache. So, reduce the cache sizes, in Adv. Config. to "Advisable" level, or to a value lower than what you have, and you will notice the difference and hopefully, like mine, the device will run snappier. Hope this helps.
I use those settings and my memory usage hovers around 39-43 with no programs open.
Memory vs. speed
This is a common misconception from the times when devices had 20MB free after boot.
Let's face the truth: free memory is not making your system go faster, it's the other way around actually.
Large cache is in place to offload some stress from the storage and CPU, if you decrease caches you WILL get more free memory BUT slow down your system FULLSTOP.
Remember 50% is still about 120MB free, you pretty much need <25MB for anything you may be doing with the phone.
Unused memory = wasted memory. - it's that simple.
But on the other hand, less memory MAY indicate your device is running more services and processes at startup, that can use your CPU and potentially slow down your system with CPU spikes and even drain your battery.
The best way to speed up your device is:
* Use tool like MemMaid and disable unnecessary startup items and services.
* Do a storage cleanup with memmaid or cache cleaner.
* Delete unnecessary files from "\windows" folder (like all .htm help files or installation logs .log/.txt ).
* Pump up caches in Advanced Config, use the largest system caches you are allowed, you have plenty of memory, use it!
* Optionally make registry adjustments to pump up the cache even higher than tweaking tools allow (especially FATFS at 32768 and GDI Glyph cache at 524228)
* Modify your ROMs before flashing and increase PagePool size to 16-24MB
That's about it, I have about 52% of memory (not using HTC Taskman or TouchFlo3d) and my phone flies!
Making the following change caused my phone to get stuck during startup if I had my memory card in:
HKLM\System\Storagemanager\Fatfs and change key Cachesize from 16384 to 32768
Click to expand...
Click to collapse
As soon as I changed it back down to 16384 it booted right up.
It is quite possible, as I poined out these registry tweaks are optional and they push the cache above recommended limits, such action may introduce compatibility problems with some SD cards but neither of them should prevent your system from booting.
nik3r said:
It is quite possible, as I poined out these registry tweaks are optional and they push the cache above recommended limits, such action may introduce compatibility problems with some SD cards but neither of them should prevent your system from booting.
Click to expand...
Click to collapse
It only got stuck with the memory card in. If I took it out it would boot fine, and I could insert it after it booted and it would work fine. Strange.
Anyway, I moved it back down and all is well again.
Just stumbled over this thread.
VERY uncommon that the phone get's stuck at boot with the SD card inserted and changed cache/memory settings. Could be related to the fact that a "system oriented program" was installed on the SD (shell programs, IE cache files moved to SD etc.).
You may try to install the attached cab (supposed to speed up SD access slightly).
Furthermore, check in windows\startup what programs are loaded and what you really need.
Hint: People running WeFi will find a WeFi link which eats easy 5 megabytes - it's a non required pre-loader.
Just delete and WeFi will still run without problems.
The Raph/Fuze themselves do not suffer memory starvation like other devices with much smaller RAM and I have to agree with nik3r that almost all current PPC programs are running on 20 - 28 meg of required RAM where in my tests 28 meg were only needed for iGO8 with TTS calculating a bicycle route of ~ 350 miles. Other tests showed ~ 5 meg for the TF3D audio player with 1000+ songs on the device and ~ 20 meg RAM running a DVD rip under coreplayer (full movie size 380 megabytes).

[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

not clear to me from search what is current state of swap && / || CCache

Can anyone direct me to a guide somewhere?
I'd like to make an ext partition? Or would I? Is Swapper 2 just as fast? Tradoffs? Anyone run into their sd card wearing out yet?
bueler?
The message you have entered is too short. Please lengthen your message to at least 10 characters.
The consensus seem to be "do not use" except as 'last resort', and only needed on phones with 256MB or less of mem.
I wrote this, and I am waiting for a technical review from some experts in this field.
http://forum.xda-developers.com/showthread.php?t=897823
kschang said:
The consensus seem to be "do not use" except as 'last resort', and only needed on phones with 256MB or less of mem.
I wrote this, and I am waiting for a technical review from some experts in this field.
http://forum.xda-developers.com/showthread.php?t=897823
Click to expand...
Click to collapse
I have 256MB ram
At the moment, Compcache is good enough, but I can't help but wonder how much better it could be with swap instead of Compcache.
edit: "For example, If you have a 256MB system (shows as 262MB due to 1024 vs. 1000 KB size difference) and have 130MB of apps and data/cache loaded, then that leaves about 130MB for the system to actually RUN programs. That sounds like a lot, but in reality that is not enough, since the system itself takes 50-80MB, and services will take up another 30-50MB, leaving almost nothing. "
quick review, you don't appear to be differentiating between RAM and Flash? Having more apps installed shouldn't increase RAM usage at all. Unless I gravely misunderstand the Android OS, if I install a new program, it resides in the system flash, not the RAM, until I run it, at which point it gets loaded to RAM. When the system needs memory and no swap or Compcache is in use, it writes the state of the application to the flash and removes it from RAM.
What the swap does is similar to what compcache does-- compresses apps that are currently in RAM, and moves them to the swap space. In the case of Compcache, this is in the RAM. But since you're compressing it, background apps don't take nearly as much RAM, and you get an app switching speedboost because the processor can uncompress the compcache'd program, "move" it to RAM, compress the currently running program in RAM, and "move" it to the compcache. Forgive me if you already said this, I can't read the entire thing at the moment.
As for swap, I'm not sure if the processor compresses before going to the hard swap file, I don't think that it does-- when android starts getting low on RAM, it moves what was in RAM, to the swap on the SD-card. Since it does this when the system is low on RAM, and not when the system runs out of RAM, you never notice it. Reading the app back from the SD card happens almost instantaneously, because the sd cards can be read from at a speed of at least 20MB/s, maybe more. When you're restoring an app to RAM, 20MB/s is plenty.
edit2: I'm sorry but this guide is too vague to be anything more than moderately informative. Comments like:
-"CompCache, or "compressed cache", is handled by the Linux kernel. It takes a portion of your memory, and use it as a cache space, but compressed. By using on-the-fly compression it is able to make your memory appear to be a bit larger than it actually is. However, the result is slower performance.
This is usually NOT tweakble without mod ROM such as Cyanogen Mod. The kernel also must support this feature, and not all do. This also slows your phone. "
-"...swap space by either creating a swap file or a swap partition. This adds a lot of read/write action to your SD card and may substantially decrease its usable life."
-"This really slows your phone."
People wouldn't be doing these things for no reason. Compcache does not "make your memory appear a bit larger", when it at least doubles the amount of usable RAM-- when you allocate 60MB, if you average 75% compression (I usually see between 65% and 80%), do you know how much RAM this effectively nets you? Over at least 60MB extra, usually about 80! So my phone goes from having 256MB ram to having 340 effectively. Having your processor overclocked minimizes any slowdown from the compression/decompression; I haven't noticed any slowdown, and having the "extra" RAM definitely has made my phone more able to multitask.
You basically discourage users from doing ANYTHING like swapping, compcaching, etc to their phone, saying it "slows it down" and "can substantially decrease your SD Card's life". My experience has been otherwise regarding slowing it down, and regarding the SD card, the only part that would actually go bad is the swap partition. If you put that at the end of the drive, when it goes bad, you'll know, and you can just move the partition back 300MB and put your 300MB swap there. We haven't heard of any users' cards going bad from this yet. Also, if you have a class 6+ SD Card, they implement wear leveling on the card, so you don't need to worry about wearing out any individual bits.
Sorry, I'm just not digging it.
rancur3p1c said:
I have 256MB ram
Click to expand...
Click to collapse
Me too, me too...
At the moment, Compcache is good enough, but I can't help but wonder how much better it could be with swap instead of Compcache.
Click to expand...
Click to collapse
So try it. With CM612, I have CompCache AND Swap (through Swapper2 / 128 MB) turned on. It slows down every once in a while but my programs don't crash any more.
edit: "For example, If you have a 256MB system (shows as 262MB due to 1024 vs. 1000 KB size difference) and have 130MB of apps and data/cache loaded, then that leaves about 130MB for the system to actually RUN programs. That sounds like a lot, but in reality that is not enough, since the system itself takes 50-80MB, and services will take up another 30-50MB, leaving almost nothing. "
quick review, you don't appear to be differentiating between RAM and Flash? Having more apps installed shouldn't increase RAM usage at all. Unless I gravely misunderstand the Android OS, if I install a new program, it resides in the system flash, not the RAM, until I run it, at which point it gets loaded to RAM. When the system needs memory and no swap or Compcache is in use, it writes the state of the application to the flash and removes it from RAM.
Click to expand...
Click to collapse
At first I thought the same way you did, until I started looking in "diskusage".
According to diskusage, there is no separate RAM. 256MB is 256MB. App storage is where everything goes, and what's left is used to load services and such. The numbers I added up matches. I have 256 MB phone. 100 is for apps, which leaves about 150-160. System itself takes 50-80 (acore, gapps, phone, system...) then add a few services and you're down to 30-40 MB free to actually run the programs. The numbers seem to match up to what's shown at the bottom of "Manage Services".
I know it's weird, but perusal of Android developers kit doesn't contradict this understanding.
What the swap does is similar to what compcache does-- compresses apps that are currently in RAM, and moves them to the swap space. In the case of Compcache, this is in the RAM. But since you're compressing it, background apps don't take nearly as much RAM, and you get an app switching speedboost because the processor can uncompress the compcache'd program, "move" it to RAM, compress the currently running program in RAM, and "move" it to the compcache. Forgive me if you already said this, I can't read the entire thing at the moment.
As for swap, I'm not sure if the processor compresses before going to the hard swap file, I don't think that it does-- when android starts getting low on RAM, it moves what was in RAM, to the swap on the SD-card. Since it does this when the system is low on RAM, and not when the system runs out of RAM, you never notice it. Reading the app back from the SD card happens almost instantaneously, because the sd cards can be read from at a speed of at least 20MB/s, maybe more. When you're restoring an app to RAM, 20MB/s is plenty.
edit2: I'm sorry but this guide is too vague to be anything more than moderately informative. Comments like:
-"CompCache, or "compressed cache", is handled by the Linux kernel. It takes a portion of your memory, and use it as a cache space, but compressed. By using on-the-fly compression it is able to make your memory appear to be a bit larger than it actually is. However, the result is slower performance.
This is usually NOT tweakble without mod ROM such as Cyanogen Mod. The kernel also must support this feature, and not all do. This also slows your phone. "
-"...swap space by either creating a swap file or a swap partition. This adds a lot of read/write action to your SD card and may substantially decrease its usable life."
-"This really slows your phone."
People wouldn't be doing these things for no reason. Compcache does not "make your memory appear a bit larger", when it at least doubles the amount of usable RAM-- when you allocate 60MB, if you average 75% compression (I usually see between 65% and 80%), do you know how much RAM this effectively nets you? Over at least 60MB extra, usually about 80! So my phone goes from having 256MB ram to having 340 effectively. Having your processor overclocked minimizes any slowdown from the compression/decompression; I haven't noticed any slowdown, and having the "extra" RAM definitely has made my phone more able to multitask.
Click to expand...
Click to collapse
It also seriously depends on your SD card. I've read reports on Phandroid that said class 6 or 8 microSD cards would provide almost lag-free swaps, but that's on a G1 (which is already a slow phone).
You basically discourage users from doing ANYTHING like swapping, compcaching, etc to their phone, saying it "slows it down" and "can substantially decrease your SD Card's life". My experience has been otherwise regarding slowing it down, and regarding the SD card, the only part that would actually go bad is the swap partition. If you put that at the end of the drive, when it goes bad, you'll know, and you can just move the partition back 300MB and put your 300MB swap there. We haven't heard of any users' cards going bad from this yet. Also, if you have a class 6+ SD Card, they implement wear leveling on the card, so you don't need to worry about wearing out any individual bits.
Sorry, I'm just not digging it.
Click to expand...
Click to collapse
Constantly reading and writing the file will cause that area to get much heavier use and eventually cause it to fail the bootup "checking SD card". The only question is how much life is taken away.
I am running my Droid on 24% CompCache AND 128MB Swap right now. Occasional lag but otherwise runs quite well. It's also overclocked to 1.2 GHz with P3Droid's kernel. So I do practice somewhat of what I preach...
so if I have 512MB of ROM, and 256MB of RAM, and I fill up my ROM with programs, how much RAM do I have?
I don't follow how what you said can be.
SD Card writes-- SanDisk guarantees theirs for 100K writes to any given sector...that's good enough for the swap to not be a problem in the near future IMHO.
let's put it this way...
Here's the specs of Moto Droid from Motorola itself (http://developer.motorola.com/products/droid/)
RAM 256 MB
FLASH ROM 512 MB
USER STORAGE AVAILABLE (MAX) 256 MB
So the REST of the ROM clearly is to hold the Android OS itself. The actual programs you can load for running? 256MB. That's app storage.
I've always wondered if there's a way to read the actual ROM contents and enumerate that... But that's for another topic.
Found this useful post: boot process of Android OS
http://www.androidenea.com/2009/06/android-boot-process-from-power-on.html
Furthermore, I noticed that the "built-in" apps (i.e. bloatware) are actually just stuff left in the "system" dir which can only be accessed with root permission. So they are NOT store in "ROM" per se, but more like "part of boot rom".
I have to find explanation on how an app is loaded, but that helps...
Aha, so that's the term they used... Application Lifecycle.
http://www.youtube.com/watch?v=ITfRuRkf2TM
Okay, I take back what I said. Apps are loaded into RAM, but HOW things are allocated wasn't that clear.
From what I understand, apps, when they are killed by system, some exit gracefully by writing their instance "state" (data and cache) to app storage. Some just exits.
Browser will write the URL, for example. When the browser is "resumed", the process is loaded, then the instance loads back the URL and it's as if nothing happened.
I'll have to revise the paper, AND I haven't figured out what to say about swap and compcache yet.
Made some corrections.
On 256MB machine, 30MB is used by deep system buffers (not part of OS), another 32 for OS cache, so about 190 or so is available the OS itself to load apps and services, and just the default gapps, system, phone, and so on is about 60MB. So a fresh clean phone should ahve no more than 120-130 MB free. If you load a couple apps with autostart services, it'll quickly drop below 50MB.
http://stackoverflow.com/questions/2298208/how-to-discover-memory-usage-of-my-application-in-android
Another piece of the puzzle... The numbers at the bottom of "Manage Services" is as explained below:
(quoting from http://android-developers.blogspot.com/2010/02/service-api-changes-starting-with.html )
"Finally, along the bottom of the screen are some obscure numbers. If you know how to interpret them, this gives you a lot of information on the memory status of your device:
* Avail: 38MB+114MB in 25 says that the device has 38MB of completely free (or likely used for unrequired caches) memory, and has another 114MB of available memory in 25 background processes it can kill at any time.
* Other: 32MB in 3 says that the device has 32MB of unavailable memory in 3 unkillable processes (that is, processes that are currently considered to be foreground and must be kept running)"
The order is reversed in Android OS 2.2. Mine says
Other: 75MB in 5 Avail: 18MB + 20 MB in 3
Which should mean 75MB in 5 unterminable tasks, 18 MB free (or can be freed easily), plus another 20 MB used by 3 processes that can be killed to free up.
ProCrank says...
39911K System_server
15756K acore
12982K swiftkey
10136K DIY Screensaver (lock screen)
9392K Phone (system)
9093K ATKfroyo
6834K Terminal
3984K JuiceDefender
3785K Screebl
3482K system MMS
3329 SeePU
3244K Bluetooth
3199K SetCPU
1979K Zygote (which is Dalvik init)
1425K Mediaserver
and the rest is native system code well under 1MB in size.
If you add System_server, Phone, Zygote, Acore, and foreground app (terminal and procrank) you get about 75MB. It would be nice if that screen TELLS you which program it considers to be unterminable, but, oh well...

[Q] More RAM available

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

Categories

Resources