[G1 Android Development] overpower:
Clarifications

First off I think I should thank everyone who's submitted information. I've been meaning to provide my own tests and further information, but I've been caught up with other things and probably won't be able to add more till next week.

I agree that a performance test on compcache .5.x is slightly wasteful with .6.x almost around the corner. This test has never been about pure performance. It has been about memory management behavior.

I was trying to get information on some behavior I had been seeing with compcache and a linux managed backing swap where as the compcache got filled up, it would refuse to release memory back to the kernel. I also noticed large performance hits as compcache filled up with normal performance returning as soon as the kernel stopped using compcache as all of the info became stale/wasted. However, it appears I'm one of the few people with that configuration, so no one else has returned such information. But it has given some insight that compcache may be better at managing its memory when no backing swap is used; it appears to be releasing. (I'm not convinced that a compcache managed backing_swap is actually in use as we have no way to get stats from it, and it appears a memlimit_kb/backing_swap appears to have NO effect on the size of ramzswap. Disksize_kb seems to be the only parameter with effect, and that shouldn't be valid according to the docs we have.)

The initial post did not include my observations because I wanted the first few results to come back as double blind. No need to influence the testing out of the box.

Regardless, although cyanogen has stated his belief the slowdowns we're seeing as compcache fills related to overtaxing the bus, on a theoretical level I'm confused as a compress/decompress on data, given the same page size should be Theta(1), constant time, when related to the overall number of pages in memory. Performance losses could relate to a flaw in compcache which may or may not bite us in .6.x.

As for testing on .6.x, I would love to, but as I am actually quite new to android testing/compiling and have yet to compile a working .6.x against cyanogen's kernel. If you have one, I'd be more than willing to do testing on that version. But, following the last bug reports for .6.x, it appears there is an unresolved stats issue on the G1, which would make any numbers unreliable. Given the original developer does not have a G1, I think the only progress on this front will be from developers who are compiling from source and actively debugging and passing the info back. As I can't get a working compile myself, that takes me out of the loop outside of just theorycrafting.

Finally, to address whether a backing file will result in better performance, I'm not sure. Although the latest kernel patches have removed most of the overhead when writing to a swap file vs a swap partition, some overhead is supposed to remain. Thus the partition should still have a slight edge, whether its significant or not. I'm also not sure what performance loss the kernel gets when it has to deal with more /dev/. My understanding is it should be minimal since in the swapping context, we're gonna max at or 2 or 3, and the order of growth is probably linear if not better. (I haven't looked to confirm.)

This is true and the fact we get this behavior, but only sometimes, is currently the main reason the G1 can't really multi-task. In theory, if you have enough swap space, all programs can go into swap memory when not in use, and switching between programs should result in their swapped memory coming in to real memory as needed.

The problem is android is designed around the lowest common denominator hardware. Since the G1 has no swap, android thus has a very aggressive process killing mechanism based on the amount of free physical memory. Currently its set to 1536 kb to start terminating non-foreground processes, which means since all the popular mods always push memory below that, even swapped out processes are killed. I'm tempted to see what happens if we compile a kernel that doesn't use the low memory killer, or modifies it to swap aware thresholds, but as stated earlier, I'm currently not at the point where I can compile the kernel myself.

My hunch is that swapping in a process should be faster then a total restart. My only concern is that the phone process may get swapped out and may be too slow on swapping in for you to get the call in time. Since the phone process happens so infrequently, its a likely swap out candidate. This is where cgroups may be useful.

Yes in theory, memlimit_kb and disksize_kb are exclusive. However, ramzswap doesn't seem to enforce it. In fact, if you enable a linux_managed swap and set disksize to something bigger than memlimit, you can observe that compcache stops using any memory between the memlimit and disksize. So for example if you have a 10 mb memlimit and a 12 mb disksize, 2 megs will always be left open, and the rest will go to the linux managed backing swap.

As for swapon, the packaged version does not support explicit priorities. But the higher number always has more priority. Thus, in order to set the order of priority of swap devices, you have to enable them in order of what you want to be used.

It is not the same as swappiness. Swappiness is a measure of how aggressively the kernel will swap out inactive process memory to the swap space. Swapon priority is an absolute priority system where swap will not be used till a higher priority swap is full. If we had explicit priority, you could set two swaps to equal priority, and then the kernel could load balance swapping for io; probably not useful for us.

EDIT

As a note, the version of compcache we have does NOT process the memlimit_kb tag properly.

If you want a backing_swap, the backing_swap parameter must be first. memlimit is ignored at this point.

# insmod ramzswap.ko backing_swap=/dev/block/mmcblk0p3 memlimit_kb=8192
# swapon /dev/ramzswap0
# cat /proc/ramzswap
DiskSize:	31250 kB
MemLimit:	14680 kB
NumReads:	1
NumWrites:	0
FailedReads:	0
FailedWrites:	0
InvalidIO:	0
PagesDiscard:	0
ZeroPages:	0
GoodCompress:	0 %
NoCompress:	0 %
PagesStored:	0
PagesUsed:	0
OrigDataSize:	0 kB
ComprDataSize:	0 kB
MemUsedTotal:	0 kB
[b]BDevNumReads:	0
BDevNumWrites:	0
[/b]

Without the memlimit_kb parameter, it will default to 15% of ram, which is about 14 megs.

The bolded sections indicates there is a backing device. The bolded line is something MOST of us haven't seen before. This indicates a compcache backing_swap.