Database Info

Is 32mb of Linux swap enough?

I know we are talking about a mobile OS here, but i remember the rule of thumb for Windows pagefile being 1.5 times the amount of ram...I am assuming the pagefile memory is similiar to the linux-swap. I could be wrong. So i did some searching and i found this on linux-swap.
The key question is how much? Older versions of Unix-type operating systems (such as Sun OS and Ultrix) demanded a swap space of two to three times that of physical memory. Modern implementations (such as Linux) don't require that much, but they can use it if you configure it. A rule of thumb is as follows: 1) for a desktop system, use a swap space of double system memory, as it will allow you to run a large number of applications (many of which may will be idle and easily swapped), making more RAM available for the active applications; 2) for a server, have a smaller amount of swap available (say half of physical memory) so that you have some flexibility for swapping when needed, but monitor the amount of swap space used and upgrade your RAM if necessary; 3) for older desktop machines (with say only 128MB), use as much swap space as you can spare, even up to 1GB.
[quote/]
So now we have 97,876 kb of memory showing in free. So should the linux swap be 48,938 kb or 48 mb instead of 32? Or because we have less then 128mb of memory should we follow the rule of giving it 1.5 (192 mb) times the amount of memory?
I am about to repartition my SDCard following the 1.5x rule. I have to research which commands to use to monitor swap...anyone know them off hand?
Edit:
I found this about making a swapfile instead of swap partition:
Swap file
As well as the swap partition, Linux also supports a swap file that you can create, prepare, and mount in a fashion similar to that of a swap partition. The advantage of swap files is that you don't need to find an empty partition or repartition a disk to add additional swap space.
To create a swap file, use the dd command to create an empty file. To create a 1GB file, type:
Code:
dd if=/dev/zero of=/swapfile bs=1024 count=1048576
I think the code needs to be changed. i am testing a few things now. I believe if=/dev/zero needs to be changed to something more amoung the lines of /dev/block/mmcblk0. Everything i try is getting a "dd: can't open '/swapfile': Read-only file system" I am assuming i have to mount it as rw but im not 100% on how to do that. Any help is appreciated.
Click to expand...
Click to collapse
/swapfile is the name of the swap file, and the count of 1048576 is the size in kilobytes (i.e. 1GB).
Prepare the swap file using mkswap just as you would a partition, but this time use the name of the swap file:
Code:
mkswap /swapfile
And similarly, mount it using the swapon command: swapon /swapfile.
The /etc/fstab entry for a swap file would look like this:
/swapfile none swap sw 0 0
Click to expand...
Click to collapse

Interesting, let me know if this helps with speed, I will definitely be using it.

Thats the plan =) I am going to repartition the sdcard now with the larger swap partition and then maybe down the line...we can switch from using a 3rd partition to using the swapfile instead.

I'm considering doing the same thing. What you posted makes sense. A bigger swap partition would free up ram for more active applications. Since I'm using a Hero Rom that would probably help haha.

I've already test this theory at swap partitions beyond 32MB including 48, 64, 192, up to 1gb at varying swap partition sizes. Also I tested multiple swappiness settings (20,30,40,60,80,100). The conclusion, bigger is not always better. The larger the swap partition became, the more the system had to swap out then back into memory, which took a hell of a lot of time (upwards of 5 minutes just to go from browser to home). General rule of thumb for swap files, just make a swap file the size that is enough, not one that is huge.
Good luck with your method of swap (which already exists, through methods like the app swapper), I know there are threads floating around where people use swap files, and end up switching to compcache or a swap partition because of higher stability.

andonnguyen said:
I've already test this theory at swap partitions beyond 32MB including 48, 64, 192, up to 1gb at varying swap partition sizes. Also I tested multiple swappiness settings (20,30,40,60,80,100). The conclusion, bigger is not always better. The larger the swap partition became, the more the system had to swap out then back into memory, which took a hell of a lot of time (upwards of 5 minutes just to go from browser to home). General rule of thumb for swap files, just make a swap file the size that is enough, not one that is huge.
Good luck with your method of swap (which already exists, through methods like the app swapper), I know there are threads floating around where people use swap files, and end up switching to compcache or a swap partition because of higher stability.
Click to expand...
Click to collapse
Ahh good to know, I tried searching for linux swap and not much came up so i didn't see any threads on this. The setup seemed to run faster, but that is part of Drizzy's v2.7 updates.
What commands did you use to watch the swap partition?

I was actually one of the first people I knew to put swap on the phone but I happen to know that the swapper application does that plus more! and even back in the day when I did it I couldn't use to much or my phone would lag! I recommend either 32mb or 64 mb of swap and just default swappiness but if you use swap I also recommend to underclock your phone to 383!

kickfliprock13 said:
I was actually one of the first people I knew to put swap on the phone but I happen to know that the swapper application does that plus more! and even back in the day when I did it I couldn't use to much or my phone would lag! I recommend either 32mb or 64 mb of swap and just default swappiness but if you use swap I also recommend to underclock your phone to 383!
Click to expand...
Click to collapse
I would only underclock if ur running hero...this seems to be the only rom underclocking really benefits you

damnitpud said:
Ahh good to know, I tried searching for linux swap and not much came up so i didn't see any threads on this. The setup seemed to run faster, but that is part of Drizzy's v2.7 updates.
What commands did you use to watch the swap partition?
Click to expand...
Click to collapse
in terminal type:
$free
it will show a section for swap. if it reads all zeros then the swap isn't being used.
Here's an example of my phone:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
You can see the difference of the swap being used, and the swap not being used.

damnitpud said:
I know we are talking about a mobile OS here, but i remember the rule of thumb for Windows pagefile being 1.5 times the amount of ram...I am assuming the pagefile memory is similiar to the linux-swap. I could be wrong. So i did some searching and i found this on linux-swap.
The key question is how much? Older versions of Unix-type operating systems (such as Sun OS and Ultrix) demanded a swap space of two to three times that of physical memory. Modern implementations (such as Linux) don't require that much, but they can use it if you configure it. A rule of thumb is as follows: 1) for a desktop system, use a swap space of double system memory, as it will allow you to run a large number of applications (many of which may will be idle and easily swapped), making more RAM available for the active applications; 2) for a server, have a smaller amount of swap available (say half of physical memory) so that you have some flexibility for swapping when needed, but monitor the amount of swap space used and upgrade your RAM if necessary; 3) for older desktop machines (with say only 128MB), use as much swap space as you can spare, even up to 1GB.
[quote/]
So now we have 97,876 kb of memory showing in free. So should the linux swap be 48,938 kb or 48 mb instead of 32? Or because we have less then 128mb of memory should we follow the rule of giving it 1.5 (192 mb) times the amount of memory?
I am about to repartition my SDCard following the 1.5x rule. I have to research which commands to use to monitor swap...anyone know them off hand?
Edit:
I found this about making a swapfile instead of swap partition:
Swap file
As well as the swap partition, Linux also supports a swap file that you can create, prepare, and mount in a fashion similar to that of a swap partition. The advantage of swap files is that you don't need to find an empty partition or repartition a disk to add additional swap space.
To create a swap file, use the dd command to create an empty file. To create a 1GB file, type:
Code:
dd if=/dev/zero of=/swapfile bs=1024 count=1048576
/swapfile is the name of the swap file, and the count of 1048576 is the size in kilobytes (i.e. 1GB).
Prepare the swap file using mkswap just as you would a partition, but this time use the name of the swap file:
Code:
mkswap /swapfile
And similarly, mount it using the swapon command: swapon /swapfile.
The /etc/fstab entry for a swap file would look like this:
/swapfile none swap sw 0 0
Click to expand...
Click to collapse
We switched from the swap file to the swap partition because it turned out that the swap partition was more stable wand was faster too. Also, we didn't have to set it up each time we flashed a new ROM and we could just have it activated by default. The problem with the swap file is that if you place it on the fat32 portion of your sdcard and then mount it to the computer, all hell breaks loose on your phone. I corrupted my card and was forced to re-partition everything because of that. As it is, I'm happy with my 32MB of swap with default swap of whatever the ROM dev chooses.
Click to expand...
Click to collapse

All this info is very good. Thank you everyone who replied. A lot of this info must be stashed away in an older thread somewhere no?
But after all this im going to give up on the swapfile and swap size. I do have a question for some of you that know more about this then me.
I want to run Hero after getting used to it. but after a few hours of running it, it slows down. i have followed every step the ROM devs have said and it still slows down. So i am wondering now, i noticed that Drizzy's ROM has an app and app_s folder in data. I am assuming that app_s is all the apps that go to the sdcard. But even a class 6 card is slower then the internal storage. So maybe moving apks like Rosie and some system apks to internal storage could speed up the way it Hero runs...am i wrong here or going down a path others have already tried?

damnitpud said:
All this info is very good. Thank you everyone who replied. A lot of this info must be stashed away in an older thread somewhere no?
But after all this im going to give up on the swapfile and swap size. I do have a question for some of you that know more about this then me.
I want to run Hero after getting used to it. but after a few hours of running it, it slows down. i have followed every step the ROM devs have said and it still slows down. So i am wondering now, i noticed that Drizzy's ROM has an app and app_s folder in data. I am assuming that app_s is all the apps that go to the sdcard. But even a class 6 card is slower then the internal storage. So maybe moving apks like Rosie and some system apks to internal storage could speed up the way it Hero runs...am i wrong here or going down a path others have already tried?
Click to expand...
Click to collapse
Actually class 6 is faster than internal storage, someone benchmarked the two in another thread that I can't currently find. Other people have tried already, it's probably best to read the first post of each hero thread, and make connections as to what dev's are doing, and what they're not doing. Their latest builds tend to be improvements upon previous builds, so if rosie and all the apk's are on the sdcard, its probably there for a reason whether it be speed or stability.

andonnguyen said:
Actually class 6 is faster than internal storage, someone benchmarked the two in another thread that I can't currently find. Other people have tried already, it's probably best to read the first post of each hero thread, and make connections as to what dev's are doing, and what they're not doing. Their latest builds tend to be improvements upon previous builds, so if rosie and all the apk's are on the sdcard, its probably there for a reason whether it be speed or stability.
Click to expand...
Click to collapse
I am going to research class 6 speeds, I can't see a memory card being faster then internal storage. but I've been wrong in the past...many times heh =)
Yeah the Drizzy ROM is a huge improvement in speed then the others...But there is still quite a bit of lag. I hope they can get Hero running as smooth as JF or Cyanogen's ROMs.

andonnguyen said:
in terminal type:
$free
it will show a section for swap. if it reads all zeros then the swap isn't being used.
Here's an example of my phone:
Click to expand...
Click to collapse
your free shows 97860 total ram, mine with cyanogen 3.9.1 shows 97880 totaly ram, but the phone is supposed to have 192megs of ram. what gives?

Sirus20x6 said:
your free shows 97860 total ram, mine with cyanogen 3.9.1 shows 97880 totaly ram, but the phone is supposed to have 192megs of ram. what gives?
Click to expand...
Click to collapse
Mine in TouchFlo 3D 2.7 shows 98328 for ram. The phone has 192mb of memory but not all of it is user accessible. Not sure why.
Edit:
Just found this on a site:
free will report slightly less memory as being in a computer than the actual total. This is mostly because the kernel (i.e., the core of the operating system) cannot be swapped out (i.e., the kernel always remains in main memory while the computer is in operation), and thus the memory that it occupies can never be freed. There can also be regions of memory that are reserved for other purposes, according to the specific system architecture.

Sirus20x6 said:
your free shows 97860 total ram, mine with cyanogen 3.9.1 shows 97880 totaly ram, but the phone is supposed to have 192megs of ram. what gives?
Click to expand...
Click to collapse
Some of the ram has been allocated for the function of phone and OS running

a 100 meg kernel? my computers kernel is less than 3 megs lol. I imagine that a few megs are saved for a frame buffer, and the os takes up most of the rest but still that's almost exactly half the phones ram. it seems like 100 megs is rather large for a phone OS

I remember windows XP taking half of the basic prebuilt computer's RAM when it first got released. it's not impossible. This IS the first hardcore phone os we've seen like android

So now we have 97,876 kb of memory showing in free. So should the linux swap be 48,938 kb or 48 mb instead of 32? Or because we have less then 128mb of memory should we follow the rule of giving it 1.5 (192 mb) times the amount of memory?
Click to expand...
Click to collapse
In all of the linux systems I have built over the years I have always used 1.5x as the rule... possibly more if I expected that I would upgrade RAM later on. I have always used a swap partition(keeps things nice and clean), but the ability to swap to a file has been around for years. All of the material I've read on the subject maintains that the file is just as fast as a swap partition, though I am willing to bet its lsightly slower due to FS overhead, though this out to be minimal - possibly a bigger deal on a slow embedded system like the G1..
I am going to research class 6 speeds, I can't see a memory card being faster then internal storage. but I've been wrong in the past...many times heh =)
Click to expand...
Click to collapse
Its all in the type of flash chip used and its interface... the interfaces are likely fairly equal(if not exactly the same). The speed of the actual media is entirely dependent on what you spend on it... in all cases for use as swap the speed is SLOW.
So maybe moving apks like Rosie and some system apks to internal storage could speed up the way it Hero runs...am i wrong here or going down a path others have already tried?
Click to expand...
Click to collapse
Sounds reasonable if the internal flash is faster than the flash on the sd card.
What commands did you use to watch the swap partition?
Click to expand...
Click to collapse
You might be interested in the output of the vmstat command(not sure if its available on android) and the file /proc/meminfo (similar to the free command).
You can also watch disk(flash) io in real time with the iostat command....
I did some testing on a random 1GB un-classed sd card I have here and I got 9MB/s writes and 12MB/s reads dding the entire card in Ubuntu.... I used this on the G1 with a swap partition and it lead to lots of force closes and long delays. Flash media will not be an ideal media for a swap file until read/write speeds approach 40MB/s or better and even then will still cause slow operation while swapping(just like a PC).
Based on the many factors with the speed of the platform.... the G1 either needs more actual RAM(find out whats up with the piece we can't get to), or less apps running simultaneously to maintain snappy speed.... and maybe some less heavy apps... 12 MB's of allocated memory is a LOT on a platform with only 96MB available to begin with....

IIRC someone ran benchmarks and found the internal flash mem was almost equivalent to a class 4 card (approx 4 MBps), this particular class 6 card im running right now is almost 8 MBps nearly double the speed of the internal flash memory

[g1] Partitioning The Ram?

I understand that this probably will get moved and placed elsewhere under some long post but I'd like to make an individual thread and catch the eyes of people who wouldn't go through those threads to find this.
Any who can we partition the Ram like we did the sd card for apps?
Why?
To set and limit core apps and fix force closings [possibly] and making space for third party apps to run smoothly.
I don't know if it is possible but I do think it is a beautiful idea.

No, there's no way to accomplish anything like that(at least nothing I've ever heard of and I'm a software engineer)

I'm glad that you feel your idea is more important than everyone elses.
No, you can't partition RAM.

i don't know about android OS but ram drives can be created in linux
ram drive is important for ssd users and is created with tmpfs in fstab

There already are memory usage limits set for different types of applications. You can see this in init.rc. But it's not practical to "partition" the memory or limit the memory used by backgroud apps. As you can see the default policy is actually biased towards background services, etc.

samygent said:
i don't know about android OS but ram drives can be created in linux
ram drive is important for ssd users and is created with tmpfs in fstab
Click to expand...
Click to collapse
Yes, they can be created in Android. That is what compcache uses. But from what I read in the OP, that isn't what he is looking for. Maybe I misunderstood him but it sounded like he wanted to limit certain applications from being able to use too much memory. A RAM drive is available to the OS to manage, right? I don't know of any way to stop a specific application from using a RAM drive.

could he be talking about like how the spl partitions data cache and system?

you mount the ram drive like a normal disk and copy whatever files you want on that partition but sadly everything is lost when you reboot
i would like to try it but i don't want to brick my phone by messing up with my fstab

I think i understand he's question. Would it be possible to use g1 internal memory only for hungry tasks and swap partition for the rest ?
I wish it was but sadly it not possible. I hate it too when some silly task take internal memory space with is way faster then sd swap speed
and now that i think about it , ram drive would'nt really help simply because android applications take very low space on drive

samygent said:
you mount the ram drive like a normal disk and copy whatever files you want on that partition but sadly everything is lost when you reboot
i would like to try it but i don't want to brick my phone by messing up with my fstab
Click to expand...
Click to collapse
I was trying to do it based on some stuff I googled. I can't get it to work. It may not have support for it by default. It could be that Compcache loads what it needs to so that it can create a Ramdisk.
Post the steps that you would use and I will try it. It won't brick my phone, I'll just have to wipe and reload which is no big deal.

not gonna mess with fstab for the moment but you can try this
create a dir somewhere, mkdir -p /system/ram
and then
mount -t tmpfs -o size=5M,mode=0744 tmpfs /system/ram
you now have a 5mb ram drive
copy something on it to test

samygent said:
not gonna mess with fstab for the moment but you can try this
create a dir somewhere, mkdir -p /system/ram
and then
mount -t tmpfs -o size=5M,mode=0744 tmpfs /system/ram
you now have a 5mb ram drive
copy something on it to test
Click to expand...
Click to collapse
It might have to wait until I get off Hero but I will try it.

i'm using hero
funny thing is , i created a 100 mb ram drive, copy something on it and umount it. swap is almost full and 35mb free on internal ram
then tried to start hero browser and it started in about less then 2 secs

samygent said:
i'm using hero
funny thing is , i created a 100 mb ram drive, copy something on it and umount it. swap is almost full and 35mb free on internal ram
then tried to start hero browser and it started in about less then 2 secs
Click to expand...
Click to collapse
Interesting. Try setting it as a swap device. Are you sure it created it from RAM? Is there really 100Mb of RAM free?

yup my hero is a lot faster now
create ram partition, copy big ass file ( 80 mb hero file ) phone is very slow
ram and swap are used up to 100%
umount the ram partition , 50 mb free on internal ram and 50 mb used on swap partition
internal ram goes down to 1-2 mb free space after a few seconds but phone is very damn fast and swap is still filled up to 50 mb

samygent said:
yup my hero is a lot faster now
create ram partition, copy big ass file ( 80 mb hero file ) phone is very slow
ram and swap are used up to 100%
umount the ram partition , 50 mb free on internal ram and 50 mb used on swap partition
internal ram goes down to 1-2 mb free space after a few seconds but phone is very damn fast and swap is still filled up to 50 mb
Click to expand...
Click to collapse
You are basically just forcing the phone to use all swap instead of RAM. Some people set their swapiness to 100, which makes the phone use swap whenver possible. It's strange that swap would perform better than internal RAM. I have some ideas for making Hero run better but I can't get Compcache running on JACxHEROski. Which Hero are you running?

miketaylor00 said:
You are basically just forcing the phone to use all swap instead of RAM. Some people set their swapiness to 100, which makes the phone use swap whenver possible. It's strange that swap would perform better than internal RAM. I have some ideas for making Hero run better but I can't get Compcache running on JACxHEROski. Which Hero are you running?
Click to expand...
Click to collapse
You need to do it via rzstool

And her I thought I was an idiot for not being able to get get compcache running thru the userinit....

I'm sorry to hear that this seams like it can't be done currently but I'm glad I at least created some good conversation amongst everyone.
My whole idea for this was to partition the core apps and limit them/section them to only a certain amount of space to avoid them from force closing since they could have an appropriate amount of dedicated ram to keep them going clean and strong then after all that was taken care of third party apps could have a little space left to run a lot better.
I guess I'm more so just thinking about sectioning off the ram to apps then third party apps.

First off, don't get compcache running through userint.sh edit the user.conf file.

Compcache. Swappiness ?

With enabled compcache, and swapppiness set to 10
I have the following
free
total used free shared buffers
Mem: 195916 193708 2208 0 12
Swap: 131064 105536 25528
Total: 326980 299244 27736
#
I'm pretty noob at all this, but I'm learning.
Is 10 swappiness a default setting ? compcache.sh has this
/system/xbin/insmod /system/lib/modules/lzo_decompress.ko
/system/xbin/insmod /system/lib/modules/lzo_compress.ko
/system/xbin/insmod /system/lib/modules/xvmalloc.ko
/system/xbin/insmod /system/lib/modules/ramzswap.ko disksize_kb=131072
/system/xbin/swapon /dev/block/ramzswap0
echo "10" > /proc/sys/vm/swappiness
What if I increase the swappiness from 10 to 60 ?
Do my memory numbers look OK ? I'm a bit worried about my free numbers ?

grifforama said:
With enabled compcache, and swapppiness set to 10
I have the following
free
total used free shared buffers
Mem: 195916 193708 2208 0 12
Swap: 131064 105536 25528
Total: 326980 299244 27736
#
I'm pretty noob at all this, but I'm learning.
Is 10 swappiness a default setting ? compcache.sh has this
/system/xbin/insmod /system/lib/modules/lzo_decompress.ko
/system/xbin/insmod /system/lib/modules/lzo_compress.ko
/system/xbin/insmod /system/lib/modules/xvmalloc.ko
/system/xbin/insmod /system/lib/modules/ramzswap.ko disksize_kb=131072
/system/xbin/swapon /dev/block/ramzswap0
echo "10" > /proc/sys/vm/swappiness
What if I increase the swappiness from 10 to 60 ?
Do my memory numbers look OK ? I'm a bit worried about my free numbers ?
Click to expand...
Click to collapse
Swappiness at 10 is usually good. The higher the number the more often it will swap. On an sd card this means lower life. When speaking of compcache however, not using the sd card, it means more cpu usage. So you can play with higher numbers but usually between 10 and 60 are good. I wouldnt go above 60 btw.

I don't know if this is along the same lines but I had an older app still on my external harddrive from my old T-Mo G1 called Swapper.apk. I moved to my SD Card last night,installed it,set it up and turned on swappiness and set it up. It updated from the android market as well today. my swap size is 256 MB. and had my swappiness set to 100. Is that too much? Everything is running fine and it seemed like it actually gave me a little more space for apps which I like(I tend to run a lot of apps)
My information says this:
Memory:195344 KB
Used: 188420
Free: 6924
Swap:250008 KB
Used:0
Free:250008
I'm kinda a noob at this swappiness stuff.Could you guys please enlighten me a little more please. I'm getting ready to try out Data2Ext2 as well to see what else I can come up with or try out Firerats again. Any info and help is greatly appreciated!

andy_lowe02 said:
I don't know if this is along the same lines but I had an older app still on my external harddrive from my old T-Mo G1 called Swapper.apk. I moved to my SD Card last night,installed it,set it up and turned on swappiness and set it up. It updated from the android market as well today. my swap size is 256 MB. and had my swappiness set to 100. Is that too much? Everything is running fine and it seemed like it actually gave me a little more space for apps which I like(I tend to run a lot of apps)
My information says this:
Memory:195344 KB
Used: 188420
Free: 6924
Swap:250008 KB
Used:0
Free:250008
I'm kinda a noob at this swappiness stuff.Could you guys please enlighten me a little more please. I'm getting ready to try out Data2Ext2 as well to see what else I can come up with or try out Firerats again. Any info and help is greatly appreciated!
Click to expand...
Click to collapse
That should be fine though 64 might be better. I remember with the G1 if you had swappiness set up higher than 64 you got bad performance. Just remember unless you're low on space on your phone a swap file may actually lower performance.

Thanks!
chuckhriczko said:
That should be fine though 64 might be better. I remember with the G1 if you had swappiness set up higher than 64 you got bad performance. Just remember unless you're low on space on your phone a swap file may actually lower performance.
Click to expand...
Click to collapse
Thank You for your input,I have adjusted it to 64 and it actually is running a bit better and smoother for some reason!!

[REQUEST] Move App-Data to/back from /data to /sd-ext

Are there any plans to implement a Button into the App-Manager, to move the Data-Part of an app to the /ext2 Partition ?
Especially on low memory devices (like the G1) this will give us the chance to install a lot of apps without runnung to "low space on device".
I have written a very small bash-script to manually do this job, but it would be more comfortable with a Button.
move.sh
Code:
#!/system/bin/sh
#
#data_to_move=com.alk.copilot
#data_to_move=com.camelgames.blowup
#data_to_move=com.drodin.tuxrider
#data_to_move=com.gameloft.android.AMEU.GloftAsphalt5.asphalt5
#data_to_move=com.navigon.navigator
#data_to_move=com.polarbit.ironsightlite
#data_to_move=com.polarbit.ragingthunder
#data_to_move=com.polarbit.rthunder2
#data_to_move=com.polarbit.waveblazerlite
#data_to_move=com.estrongs.android.pop
su
mount -o remount,rw /data
mkdir /sd-ext/data
cd /data/data
echo About to Move ${data_to_move}
cp -r -p ${data_to_move} /sd-ext/data
rm -r -f ${data_to_move}
ln -s /sd-ext/data/${data_to_move} ${data_to_move}
unmove.sh
Code:
#!/system/bin/sh
#
#data_to_move=com.alk.copilot
#data_to_move=com.camelgames.blowup
#data_to_move=com.drodin.tuxrider
#data_to_move=com.gameloft.android.AMEU.GloftAsphalt5.asphalt5
#data_to_move=com.navigon.navigator
#data_to_move=com.polarbit.ironsightlite
#data_to_move=com.polarbit.ragingthunder
#data_to_move=com.polarbit.rthunder2
#data_to_move=com.polarbit.waveblazerlite
#data_to_move=com.estrongs.android.pop
su
mount -o remount,rw /data
mkdir /sd-ext/data
cd /data/data
echo About to unMove ${data_to_move}
rm ${data_to_move}
mkdir ${data_to_move}
cp -r -p /sd-ext/data/${data_to_move} ${data_to_move}

Apps that need lots of space should use the fat32 partition gracefully, using this hack would considerably slow down your system(even class6). Why double the reads and writes to the slow mmc?

Because not all apps using the fat32-Partition.
Navigon for example uses 14 MB of internal storage.
If you install such apps on a G1, you can quickly run out of space.
Low on cache space will considerably slow down the overall system performance.
I would not suggest to move the data of any installed apps, but from the big ones.
Apps like Navigation and 3D-Games are writing not frequently their data and if you own a G1 you are already swapping when using an Eclaid based ROM. So this wouldn't make a big difference in the livetime of your sdcard.
Perhaps someone could implement a partial move (e.g. only libraries) to avoid massive writes to the card ... and/or setting a threshold value, so apps with small data could not be moved.
For me, moving the apps in the Script above has given me additional 35 MB internal space and everything is still runnung "fast".

/data/data
TheGenesis said:
Because not all apps using the fat32-Partition.
Navigon for example uses 14 MB of internal storage.
If you install such apps on a G1, you can quickly run out of space.
Low on cache space will considerably slow down the overall system performance.
I would not suggest to move the data of any installed apps, but from the big ones.
Apps like Navigation and 3D-Games are writing not frequently their data and if you own a G1 you are already swapping when using an Eclaid based ROM. So this wouldn't make a big difference in the livetime of your sdcard.
Perhaps someone could implement a partial move (e.g. only libraries) to avoid massive writes to the card ... and/or setting a threshold value, so apps with small data could not be moved.
For me, moving the apps in the Script above has given me additional 35 MB internal space and everything is still runnung "fast".
Click to expand...
Click to collapse
there is already a script in existance to move things like that:
# lucid -d -sd
would move app data to the sdcard and symlink .. this (however) does not move individual pieces .. i would be interested to know the speed difference on these apps that you moved .. also .. this will create extra difficulty when attempting any nandroid backup/restore .. i have seen people putting up comments because their phone crashed due to the excessive number of symlinks across the phone .. if you are not careful with them you could lose all your data

The Space allocated by the "big apps" is mainly used by their ./lib dir. Because of this, it would be enough to move and symlink only those dirs.
With Games the "rest" goes to settings and scores.
On a G1 there is absolutely no difference in speed when moving data to sd.
Perhaps its because the G1 is not the top performer at all
I have played those games in the list with data in internal and on sd-ext and there is no difference in speed ... loading time is also the same.
I'm satisfied with the results, but these scripts didn't remove the data when apps where uninstalled or re-installed and thats the reason of my request.
Take a look on your storage and see how much space (libraries) should be on the sdcard.
Code:
du -sk /data/data/* | sort -rn | head
btw ... did you ever enabled JIT on a G1 and played ExZeus or Armageddon Squadron ?
Its amazing what is possible on this "outdated" Hardware!
P.S. Nandroid Backup runs perfectly with this symlinks (no recursive/double Backups)

Update:
Nandroid Backup only saves app and app-private ... could you edit this to save everything excluding "crap-dirs" ?
If nandbackup uses standard tar calls, you can use the following command:
Code:
tar pcvf /sdcard/nandroid/sd-ext.tar . -C /sd-ext --exclude dalvik-cache --exclude lost+found
... it would save everything the user place on the partition including userinit.sh
Restoring such a tarball works perfectly with nandbackup.
Thx in advance
Thom

Int. mem for SWAP ?
well, after the moving some heavy apps data
I have 54mb free Int. mem (out of 90)
is that possible to use 24-32mb of this (fast?)memory
for SWAP ? instead of linux swap
and does it make any sense?
...just tried to enable /swapfile.swp via Swapper2
though it says
-creating swap - ok
-changing permission - ok
-formatting swap - ok
but
- enabling swap(file) - FAIL
sorry if it's just another stupid question
G1, stock cm5.0.8 test4, 32mb linux swap

TheGenesis said:
Update:
Nandroid Backup only saves app and app-private ... could you edit this to save everything excluding "crap-dirs" ?
If nandbackup uses standard tar calls, you can use the following command:
Code:
tar pcvf /sdcard/nandroid/sd-ext.tar . -C /sd-ext --exclude dalvik-cache --exclude lost+found
... it would save everything the user place on the partition including userinit.sh
Restoring such a tarball works perfectly with nandbackup.
Thx in advance
Thom
Click to expand...
Click to collapse
Have you tried BART? http://forum.xda-developers.com/showthread.php?t=562292
It's included in the recovery, and lets you backup/not_backup whatever you want.

zelipukin said:
well, after the moving some heavy apps data
I have 54mb free Int. mem (out of 90)
is that possible to use 24-32mb of this (fast?)memory
for SWAP ? instead of linux swap
and does it make any sense?
...just tried to enable /swapfile.swp via Swapper2
though it says
-creating swap - ok
-changing permission - ok
-formatting swap - ok
but
- enabling swap(file) - FAIL
sorry if it's just another stupid question
G1, stock cm5.0.8 test4, 32mb linux swap
Click to expand...
Click to collapse
It's not a stupid question ... I have had the same Idea yesterday ...
I have googled about life spawn of the internal flash memory, but I haven't found any satisfactory answer yet.
Anywhere here who know how fast the internal flash is ?
What about write cycles and wear levelling ?
If it has no integrated wear levelling, swapping will kill the phone in a few days.
I think your enable swap has failed due to wrong permissions ... try to enable with a defered call in your userinit.
Update: I have checked my filesystem ... /cache has actually 29 MB free ... is it correct, that /cache is only used by OTA updates ? Probably we can create a priorized swap there in addition to ext.

Keep up the good work dude...this sounds great

TheGenesis said:
Navigon for example uses 14 MB of internal storage.
If you install such apps on a G1, you can quickly run out of space.
Low on cache space will considerably slow down the overall system performance.
I would not suggest to move the data of any installed apps, but from the big ones.
Apps like Navigation and 3D-Games are writing not frequently their data and if you own a G1 you are already swapping when using an Eclaid based ROM. So this wouldn't make a big difference in the livetime of your sdcard.
Perhaps someone could implement a partial move (e.g. only libraries) to avoid massive writes to the card ... and/or setting a threshold value, so apps with small data could not be moved.
For me, moving the apps in the Script above has given me additional 35 MB internal space and everything is still runnung "fast".
Click to expand...
Click to collapse
If navigon is using that much internal storage it's a very poorly written application. Low cache doesn't slow the system down, just apps that require such huge amounts of it.
I'm already swapping when using Eclair? Wrong, using swap on the sdcard is horrible, I'd never recommend it to anyone and I personally don't use it. I have 114 apps installed and my cache is 9% used, it seems to me like your apps aren't clearing their cache correctly, or they're just poorly written. The argument that 'you are already swapping so this wouldn't make a big difference in the livetime of your sdcard' is untrue, you are effectively doubling the amount of read/writes to the mmc, if not more, so the lifetime could potentially be cut in half, of course depending on use.
I'd say nice try, but this really just working around crap apps.

I use a 16 GB class 6 SD-Card with static wear-levelling.
Assuming that a standard-flash-nand-cell lasts about 10.000 write cycles, and my swap-write-turnover is currently about 1,6 GB per day, my SD-Card will last about 273 years (minus regular writes).
So I don't care about livetime.
Besides Navigon, there are many apps, that store their huge libraries to /data .... Games in most cases ... If you aren't using "bad written apps" its fine for YOU ... everyone else has to do some tweaks when installing some of them to the limited internal storage.
I have 278 apps installed and the only limit for me, is currently the free space on my sdcard.
If you haven't enabled swap since you have flashed your first Eclair ROM, you have probably never felt what is "speed" or you never need more than 1 app running simultaniously .... or you are using a different phone instead of a G1
You say "swapping to sd is horrible" ... I think you have used the wrong parameters ... when I diable swapping my system is lagging ... even when I work with one app the same time.
Did you enabled compcache while swapping ? Did you use a swapfile on FAT32 ? Is your swappinness levor 50 or above 60 ? Are you using al class 4 or slower sd-card ? Are you running heavy memory consuming apps without killing them from time to time ?
All these can turn a fast swapping system into an unusable phone.
You cannot enable swap and use the system like before.

Update:
I have copied 18 MB from cache to data and it tooks round about 18 seconds.
Same file from sdcard (FAT32) to sdcard tooks 6 seconds ...
I will use the sdcard

I should have listened to internal voice telling me not to argue with a fool cause people might not know the difference..

Something strange
I did some stupid (owing to absence of linux knowledge)
experiments regarding to swap_2_/
I believe if it possible it should be done through userinit/config
or smth during boot to enable r/w. give necc permissions etc.
I just used Swapper and RootManager
If I create .swp (it creates but does not work) in any place but /cache
it (just existence of this file) does system unstable, slow and unresponsive
in /cache or any existing or newly created folders inside /cache/ it's OK
before reboot when those new folders/files disappear
=
After a wile something happened with my phone (not a first or last time)
many apps caused FC, settings were lost etc
tried "fix uid missmatches" - dots filled out numerous screens
and after ~20min I decided to reboot
tried nandroid - same endless ....................................................
after the reboot I found no FCs but still missing settings for some apps
(sim_linked_data apps like CoPilot were OK) so I Titaniumed non-working apps
data (5-6 apps) and evrthng seems fine
=
BUT when I look at internal memory available
I find 73Mb (out of ~90) FREE
there was 53Mb free before the accident
Is that normal? And whats the limit?
I have my laps and brain scratched to find some application of this
=
just my experience
-compcache always gives me horrible slow phone - not using
-linux swap - best results compare to no_swap - allways use

Some apps are storing many data to /data and sometimes to /cache.
I think your restores have cleared some of them.
Try CacheMate instead of such manouvers

I have checked the write throughput using dd:
Internal Storage: 3,5 MB/s
Class 6 SD Card: 7 MB/s
... annoying ... USB to SD-Card is 3,5 MB/s and SD-Card via Card-Reader (PC) is about 9 MB/s.

Hey man, i had the same problem and decided to go a head and write a small tool that does exactly this, this is a UI tool that shows all the folders in /data/data (excluding system folders) and let you move your apps to your sd, you should have an APP2SD ROM installed with root (of-course) and sd card partitioned to EXT and FAT32.
Contact me if you want to check it out, i never found the time to publish it ([email protected])

hi,
I have tried that and it works, but...it works until reboot...
After reboot I don't see directory /sd-ext/data....
I don't know why it always been deleted....

[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