yashsingh1/xdaforums huggingface dataset:
[G1 Android Development] pinetreehater:
by the way, in case everyone missed it:

I have two G1's. Both have brand new installs of CM 3.9. One has compcache (with swapiness set to 20 and 24mb of space allocated) and one does not. After a reboot on both devices and waiting a five minutes for everything to settle, I filmed the opening of the camera app. The one without compcache is noticeably quicker. Is compcache slowing our machines down, at least in certain instances?

By the way, cat /proc/ramzswap confirms compcache is enabled.

http://www.youtube.com/watch?v=gNYv-5WLDVA

edit:swappiness for the above tests was at 60....
[G1 Android Development] thelamacmdr:
Running Cyanogen 3.8.1 with the Palm Pre theme ( dunno if it made a diff.) and HTC Music app running.

2.6.29-cm
03:53:53 up 3 min, load average: 2.22, 1.47, 0.60
60
Filename	Type	Size	Used	Priority
/dev/ramzswap0 partition	31996	11612	-1
DiskSize:	32000 kB
NumReads:	1902
NumWrites:	3415
FailedReads:	0
FailedWrites:	0
InvalidIO:	0
PagesDiscard:	0
ZeroPages:	137
GoodCompress:	72 %
NoCompress:	4 %
PagesStored:	3278
PagesUsed:	1128
OrigDataSize:	13112 kB
ComprDataSize:	4461 kB
MemUsedTotal:	4512 kB
total used free shared buffers
Mem: 97876 96488 1388 0 652
Swap: 31996 11612 20384
Total: 129872 108100 21772

Home Y
total used free shared buffers
Mem: 97876 95704 2172 0 668
Swap: 31996 11612 20384
Total: 129872 107316 22556

Browser Y

total used free shared buffers
Mem: 97876 96308 1568 0 432
Swap: 31996 15528 16468
Total: 129872 111836 18036

Home N

total used free shared buffers
Mem: 97876 86336 11540 0 468
Swap: 31996 14936 17060
Total: 129872 101272 28600

Browser Y

total used free shared buffers
Mem: 97876 95196 2680 0 520
Swap: 31996 14932 17064
Total: 129872 110128 19744

Home N

total used free shared buffers
Mem: 97876 96176 1700 0 460
Swap: 31996 15056 16940
Total: 129872 111232 18640

Browser (Opened up really quick) N

total used free shared buffers
Mem: 97876 96432 1444 0 540
Swap: 31996 15200 16796
Total: 129872 111632 18240

Home N

total used free shared buffers
Mem: 97876 96096 1780 0 540
Swap: 31996 15208 16788
Total: 129872 111304 18568
[G1 Android Development] nurre:
I'm not surprised it was.

Without compcache : Start camera app, realize your out of memory, kill another application (meaning it will start slower the next time, going through full initialization).

With compcache : Start camera, push inactive application into compcache.

I'd like to see some similar tests with more tests run. I think I might actually write a little app for this.
[G1 Android Development] sha.goyjo:
No, I apologize for being offensive. Part of my reasoning has more to do with the fact that, as far as I have seen, regardless of what works best people tend to move to the latest version. It wasn't a utility prediction. In that respect, you are going in the right direction. I do think that the plans to implement dynamic swapping between backing and ramz in the future really make a big difference, however, in any kind of work we are trying to do here. Also, from what I've looked at the difference in the modules, they look significantly different now.

I didn't mean to press your buttons, but what I'm saying does have merit.

I say this because it's not about benchmarking the current version vs. the new version. That kind of a benchmark doesn't work, because the new version has an improved feature set. Software with a larger feature set rarely performs better than software with a smaller feature set. However, the features inherent in compcache .6 are VERY compelling for android phones, specifically the ability to use backing_swap from a FILE instead of a partition. The fewer partitions on your sdcard, the better. Less wasted space, and less time spend confusing the kernel as to which /dev/ it should be writing to at the time.

As to cyanogen having "supported" your tests, there are a lot of good reasons for it. You could discover a kernel interfacing problem. You could discover a problem in the arm patch that would be relevant to the new version or upgraded versions of CM.

All I think is that the compcache project could use all the help it can get rolling out .6 for android, and that if more people helped them with that, maybe we could try and find ways to fix the version of compcache we'll be using, instead of the one we'll be moving away from.
[G1 Android Development] devsk:
One thing people need to realize is that there is no free lunch. Swap (whether the partition or compcache) is not for speeding up the system but for allowing you to run many big apps together at the same time.

swap will slow you down a bit, whether its compcache (cpu overhead for compression) or partition (I/O overhead). So, stop fooling yourself. If you want a fast phone, just use basic things and leave swap out of picture. if you want a fast phone AND want to run tonnes of stuff like touchflo, get a phone with more RAM.
[G1 Android Development] ei8htohms:
test results

Correct me if I'm wrong, but it sounds rather like you're saying, "Stop trying to make things better." Rather an odd sentiment for a Development forum, no?

I ran this test with just Calendar and Weather widgets running on the home screen and, although I have occasionally found the entire home screen slow to reload during regular use, during this test the home screen never seemed to reload at all, even with Music playing and an occasional jump to Gmail.

I'm running CM 3.9 with a simple Compcache script (no backing swap) initiated from Gscript for default disk size and 20 swappiness:

2.6.29-cm
12:23:08 up 36 min, load average: 3.37, 3.65, 2.79
20
Filename Type Size Used Priority

/dev/ramzswap0 partition 24464 6992 -1
DiskSize: 24468 kB
NumReads: 587
NumWrites: 1761
FailedReads: 0
FailedWrites: 0
InvalidIO: 0
PagesDiscard: 0
ZeroPages: 126
GoodCompress: 66 %
NoCompress: 5 %
PagesStored: 1635
PagesUsed: 602
OrigDataSize: 6540 kB
ComprDataSize: 2338 kB
MemUsedTotal: 2408 kB
total used free shared buffers
Mem: 97876 92880 4996 0 552
Swap: 24464 6992 17472
Total: 122340 99872 22468

Browser: N
total used free shared buffers
Mem: 97876 92856 5020 0 552
Swap: 24464 6992 17472
Total: 122340 99848 22492

Home: N
total used free shared buffers
Mem: 97876 92856 5020 0 552
Swap: 24464 6992 17472
Total: 122340 99848 22492

(after stressing with Music playing AND switching to Gmail)
Browser: Y
total used free shared buffers
Mem: 97876 95752 2124 0 452
Swap: 24464 7892 16572
Total: 122340 103644 18696

Home: N

total used free shared buffers
Mem: 97876 96496 1380 0 444
Swap: 24464 8276 16188
Total: 122340 104772 17568
[G1 Android Development] nurre:
And it probably doesn't, with compcache you have enough memory to keep it in, while without it needs to go through the whole onCreate and xml inflation.
[G1 Android Development] devsk:
I am not saying don't make it better. What I am saying is your expectations should be correct.

I use compcache myself. I use it with memlimit_kb=32000 disksize_kb=48000 backing_swap=/dev/block/mmcblk0p3 and a swappiness of 20. But I don't expect it to make my system fly. I just expect that more of my apps will stick around rather than killed and reloaded later. So, I am paying a little swapping cost upfront for payback later.
[G1 Android Development] ei8htohms:
any lag once compcache fills up?

Understood about managing expectations. I'm still considering the potential negative impact on battery life as well, since this is one notorious weak spot on the G1 (when it came out you didn't hear huge numbers of people complaining about how SLOW it was, but everyone complained about battery life...).

Do you mind explaining a little about your memlimit and disksize settings? I read a little about those options in the Google Code page, but I can't say I fully grokked the significance or difference.

I also can't seem to find a good explanation of how compcache and backing-swap work together. Most reports on XDA point to massive lag after compcache maxes out, but is it only then that backing-swap kicks in (and maybe a lot of those folks were using the 60 or 100 swappiness settings)? Can Linux-swap and compcache be run in parallel or separately from each other in some way (I'm guessing no)?
[G1 Android Development] uwonsum:
According to the Dev:

**********************************************************

Usage:

- modprobe ramzswap [memlimit_kb=<val>|disksize_kb=<val>] [backing_swap=<dev>]

memlimit_kb: This param is applicable only when backing_swap is given.

It is limit on amount compressed data stored in memory. Any

additional data is forwarded to backing_swap. It cannot be greater

than backing device size. If missing or 0, default value is used:

15% of RAM or backing device size, whichever is smaller.

disksize_kb: This param is applicable only when backing_swap is not given.

It is limit on amount of *uncompressed* worth of data stored in

memory. For e.g. disksize_kb=1024 means it can hold 1024kb worth of

uncompressed data even if this data compresses to just, say, 100kb.

If missing or 0, default value is used: 25% of RAM.

backing_swap: This is block device to be used as backing store for ramzswap.

It must be a valid swap partition. We move data to this device when we

encounter incompressible page or memlimit is reached. TODO: we may also

move some pages from ramzswap to this device in case system is really

low on memory.

This device is not directly visible to kernel as a swap device

(/proc/swaps will only show /dev/ramzswap0 and not this device).

Managing this backing device is the job of ramzswap module.

Examples:

1) modprobe ramzswap memlimit_kb=10240 backing_swap=/dev/sda2

sets ramzswap limit as 10MB and /dev/sda2 as backing swap device.

NOTE: here /dev/sda2 is a valid swap partition.

2) modprobe ramzswap backing_swap=/dev/sda2

same as (1) but memlimit is set to default: 15% of RAM or size of

backing swap device, whichever is smaller.

3) modprobe ramzswap disksize_kb=10240

sets ramzswap disk size as 10MB.

4) modprobe ramzswap.ko

same as (3) but ramzswap disk size will be set to default:

25% of RAM size.

Once module is loaded, activate this swap with highest priority:

swapon /dev/ramzswap0 -p 100

(-p param set swap priority)

Notes:

- ramzswap stats are exported via /proc/ramzswap

- If you give non-swap partition as backing_swap, nothing bad will happen -

swapon will simply fail to recognize /dev/ramzswap0 as swap partition.

So, in this case, unload the module and reload with correct backing_swap.

**********************************************************
[G1 Android Development] ei8htohms:
thanks! very interesting

So if I'm reading this right, memlimit and disksize would never be used together, right? And when backing_swap is NOT used, compcache is using the disksize allocation for uncompressed data, like virtual swap within RAM? Huh?

This swap priority info seems to directly conflict the info on the CompilingAndUsing page of the Google code project page:

Is 1 the highest priority or is 100 the highest priority? Is this the same as setting the swappiness? There must be a typo somewhere. Any help?

[EDIT]NVM, "-p 1" seems to be an invalid parameter.[/EDIT]

BTW, I started playing with your (rather more exotic) script from the CM Wheel of Death thread:

http://xdaforums.com/showpost.php?p=4205132&postcount=518

Have you had any further findings about the various settings employed?

Thanks again!
[G1 Android Development] devsk:
I wasn't aware that disksize_kb and memlimit_kb can't be used together. I thought the behavior would be like: if memory used by compcache reaches memlimit_kb and swap usage hasn't reached disksize_kb, swap to backing_device upto disksize_kb-memlimit_kb. That would have been my choice because it hard limits the swap usage to 48M in my case. The way it is supposed to work is that it will swap upto (swap size fitting in memlimit_kb after compression + the swap partition size), which makes it way higher than you really want because what this means is that if I am getting a 2:1 compress, I will be allowing using ~128M (64M in compcache + 64M on backing_device) of swap.

Also, the backing_device seems to be used when an incompressible page is found by compcache. This is not good. I would rather have it store it in memory and obey the memlimit_kb instead of doing an I/O.
[G1 Android Development] overpower:
We're getting the thread off topic, but I'll bite.

Yah, its compcache supposedly doesn't allow both. I don't know what happens though when you specify both. I suspect it disables the compcache managed backing swap so you're just playing with whatever your disksize is. In your case, 48 mb of ramzswap alone.

I think you just described how linux managed backing swap works. I'm a little confused by your shorthand. I assume you want 32 megs for ramzswap and then a swap usage of 48 megs total.

You can do this by doing a ramzswap of 32 megs, and then a linux managed backing swap file or partition of 16 megs. I'm not sure if there is a command to hardlimit your swapon though, so if your partition is greater than 16, linux will probably use it all if it needs it.

Finally, as for compcache behavior, take it up with the developer. :)

Edit

All the info on how to do this is in the compcache userinit thread or in the Q&A section. Here, I dug it up. If you really can't figure it out, pm me so we don't keep bumping this.
[G1 Android Development] overground:
Running build in sig. Swap partition. Swappiness=10

2.6.27.25-cm
20:01:01 up 21 min, load average: 0.49, 0.73, 1.00
10
Filename Type Size Used Priority

/dev/block/mmcblk0p3 partition 32120 25352 -1
total used free shared buffers
Mem: 98436 96736 1700 0 436
Swap: 32120 25352 6768
Total: 130556 122088 8468
sh-3.2# free HOME=Y
free
total used free shared buffers
Mem: 98436 95740 2696 0 224
Swap: 32120 25308 6812
Total: 130556 121048 9508
sh-3.2# free BROWSER=Y INSTANT
free
total used free shared buffers
Mem: 98436 96300 2136 0 340
Swap: 32120 24396 7724
Total: 130556 120696 9860
sh-3.2# free HOME=Y INSTANT
free
total used free shared buffers
Mem: 98436 97020 1416 0 352
Swap: 32120 21108 11012
Total: 130556 118128 12428
sh-3.2# free HOME=Y MUSIC=Y LAG OPENING MUSIC
free
total used free shared buffers
Mem: 98436 95836 2600 0 332
Swap: 32120 20176 11944
Total: 130556 116012 14544
sh-3.2# free BROWSER=Y MUSIC=Y GREAT LAG OPENING BROWSER
free
total used free shared buffers
Mem: 98436 96440 1996 0 352
Swap: 32120 31300 820
Total: 130556 127740 2816
sh-3.2# free HOME=YES MUSIC=YES GET F/C IN MESSAGING MUCH LAG
free
total used free shared buffers
Mem: 98436 96684 1752 0 340
Swap: 32120 32120 0
Total: 130556 128804 1752
sh-3.2# free BROWSER=Y MUSIC=Y RELOAD OF CNN.COM
free
total used free shared buffers
Mem: 98436 97044 1392 0 392
Swap: 32120 14500 17620
Total: 130556 111544 19012
sh-3.2#

Sorry if I've missed any vital info, I only read the first post.

EDIT: To clarify, this is the HTC Music player.
[G1 Android Development] uwonsum:
2.6.29-cm
23:58:29 up 3 min, load average: 5.55, 2.83, 1.11
32
Filename Type Size Used Priority
/dev/ramzswap0 partition 131064 4584 -1
DiskSize: 131072 kB
MemLimit: 14680 kB
NumReads: 111
NumWrites: 465
FailedReads: 0
FailedWrites: 0
InvalidIO: 0
PagesDiscard: 0
ZeroPages: 33
GoodCompress: 100 %
NoCompress: 0 %
PagesStored: 357
PagesUsed: 64
OrigDataSize: 1428 kB
ComprDataSize: 252 kB
MemUsedTotal: 256 kB
BDevNumReads: 14
BDevNumWrites: 75
total used free shared buffers
Mem: 97876 96124 1752 0 732
Swap: 131064 4584 126480
Total: 228940 100708 128232

total used free shared buffers
Mem: 97876 96416 1460 0 864
Swap: 131064 5004 126060
Total: 228940 101420 127520

total used free shared buffers
Mem: 97876 96196 1680 0 412
Swap: 131064 9808 121256
Total: 228940 106004 122936

total used free shared buffers
Mem: 97876 96128 1748 0 404
Swap: 131064 9816 121248
Total: 228940 105944 122996

total used free shared buffers
Mem: 97876 96552 1324 0 432
Swap: 131064 13736 117328
Total: 228940 110288 118652

total used free shared buffers
Mem: 97876 96528 1348 0 432
Swap: 131064 36424 94640
Total: 228940 132952 95988

total used free shared buffers
Mem: 97876 96232 1644 0 432
Swap: 131064 43084 87980
Total: 228940 139316 89624

total used free shared buffers
Mem: 97876 96536 1340 0 404
Swap: 131064 56348 74716
Total: 228940 152884 76056

I tested a few apps (google maps, market, gmail, soccer livescore, handycalc, pdf viewer, advance dictionary) all this while the music continued playing in the background. The browser did not reload once. I will post the result next for swappiness of 16 which I use and recommend.
[G1 Android Development] uwonsum:
2.6.29-cm
00:35:39 up 4 min, load average: 3.59, 2.68, 1.14
16
Filename Type Size Used Priority
/dev/ramzswap0 partition 131064 1812 -1
DiskSize: 131072 kB
MemLimit: 14680 kB
NumReads: 81
NumWrites: 332
FailedReads: 0
FailedWrites: 0
InvalidIO: 0
PagesDiscard: 0
ZeroPages: 29
GoodCompress: 100 %
NoCompress: 0 %
PagesStored: 213
PagesUsed: 32
OrigDataSize: 852 kB
ComprDataSize: 126 kB
MemUsedTotal: 128 kB
BDevNumReads: 8
BDevNumWrites: 90

total used free shared buffers
Mem: 97876 96192 1684 0 4940
Swap: 131064 1812 129252
Total: 228940 98004 130936
# free
total used free shared buffers
Mem: 97876 96588 1288 0 296
Swap: 131064 2600 128464
Total: 228940 99188 129752
# Google Maps
total used free shared buffers
Mem: 97876 96576 1300 0 268
Swap: 131064 3124 127940
Total: 228940 99700 129240
# Music Player
total used free shared buffers
Mem: 97876 96384 1492 0 452
Swap: 131064 3124 127940
Total: 228940 99508 129432
# Gmail: Y

total used free shared buffers
Mem: 97876 96480 1396 0 292
Swap: 131064 3600 127464
Total: 228940 100080 128860
# Advance English Dictionary

total used free shared buffers
Mem: 97876 96244 1632 0 268
Swap: 131064 3760 127304
Total: 228940 100004 128936
# Market: Y

total used free shared buffers
Mem: 97876 96460 1416 0 304
Swap: 131064 4520 126544
Total: 228940 100980 127960
# Soccer Live Score

total used free shared buffers
Mem: 97876 94840 3036 0 352
Swap: 131064 4580 126484
Total: 228940 99420 129520
# HandyCalc

total used free shared buffers
Mem: 97876 96512 1364 0 2124
Swap: 131064 7128 123936
Total: 228940 103640 125300
#PDF Viewer

This is my virtual memory kernel configuration used for both tests:

sysctl -a | grep vm
vm.overcommit_memory = 1
vm.panic_on_oom = 0
vm.oom_kill_allocating_task = 0
vm.oom_dump_tasks = 0
vm.overcommit_ratio = 50
vm.page-cluster = 1
vm.dirty_background_ratio = 10
vm.dirty_background_bytes = 0
vm.dirty_ratio = 16
vm.dirty_bytes = 0
vm.dirty_writeback_centisecs = 800
vm.dirty_expire_centisecs = 5000
vm.nr_pdflush_threads = 2
vm.swappiness = 16
vm.lowmem_reserve_ratio = 32
vm.drop_caches = 0
vm.min_free_kbytes = 1281
vm.min_free_order_shift = 4
vm.percpu_pagelist_fraction = 0
vm.max_map_count = 65536
vm.laptop_mode = 5
vm.block_dump = 0
vm.vfs_cache_pressure = 100

vm.swappiness = 32 for the first test of course.
[G1 Android Development] overpower:
Holy crap that's a big swap you got there. One thing I'd like you to try is to get as many things into swap as you can. As you switch between processes you should notice the time to load a process completely from swap should be about constant. Compare this with when the process is starting from scratch.

My initial impression of compcache having a leak seems incorrect so I think its safe to push swap hard. After swap is full you may start seeing fcs because the system is running completely out of mem. One thing to still watch out for is whether system performance does bog down as swap is filled. However its not as likely since we've crossed the memlimit border and working in the backing swap now.

Try this first with lower swappiness settings. I have found opening multiple tabs in steel is great for eating mem. Cyanogen also recommended imeem. If you can't consume the mem and everything is opening fresh then try pushing swappiness up.

I think if we can get a balanced swappiness that let's us put a lot of apps in memory, yet leaves enough space so the out of memory issues don't crop up we may be able to have some great multitasking/responsiveness.

After that cgroups to protect phone processes from being swapped out and maybe preloading the callerid screen should solve the missed call issue.
[G1 Android Development] uwonsum:
Here is the uptime/load result for the first test:

23:58:29 up 3 min, load average: 5.55, 2.83, 1.11

00:00:06 up 5 min, load average: 3.53, 2.94, 1.32

00:00:37 up 5 min, load average: 3.22, 2.91, 1.36

00:02:00 up 7 min, load average: 2.96, 2.86, 1.47

00:02:22 up 7 min, load average: 3.79, 3.05, 1.56

00:04:03 up 9 min, load average: 4.73, 3.62, 1.92

00:05:26 up 10 min, load average: 3.58, 3.48, 2.01

00:07:56 up 13 min, load average: 4.44, 4.02, 2.44

00:24:57 up 30 min, load average: 2.54, 2.75, 2.64
[G1 Android Development] sha.goyjo:
Overpower, thanks for clearing up your thoughts a little bit more. I understand what you are trying to get at, and it makes a lot more sense than just trying to either optimize or debunk/remove compcache. If I have the free time (I'm actually starting a company right now, so I'm very busy) I'll see what I can do to help.
[G1 Android Development] balazer:
wrong thread
[G1 General] AdrianK:
I bought an unbranded 4GB Class 6 card off eBay a few weeks ago and have had to back to the stock card because it only mounts about half the time. The card always mounts under Vista and Ubuntu and writes at 7MB/S so the card seems fine. Is there anything I can do to get it to work in my Dream? It's kinda annoying when I went to show off hero to my friend after saying how good it was and getting laughed at as the thing bootlooped =P
[G1 General] brian_v3ntura:
i would stick with sandisk all the way. it proved more reliable to me. i ordered a kingston 8gig and it didnt work in my g1. it kept freezing my phone.
[G1 General] AdrianK:
Ah ok, so some cards just don't work :-( I've already ordered a Transcend 8GB Class 6 before it might not arrive before I go on holiday ><
[G1 General] supremeteam256:
Shouldn't have a problem with that. Thats the kind I got and no problems at all.
[G1 General] AdrianK:
Great! Thanks for the heads up. I really cant wait to get hero running smoothly :D
[G1 General] Zappletoo:
I got a Verbatim 8Gb class 4 that freezes the phone as well.

I bought a takeMS class 6 for cheaper and it works perfectly.
[Touch Pro, Fuze Themes and Apps] mputtr:
I'm looking for a software that will work in conjunction with my gps to show live traffic status. I'm currently using Garmin XT and I'm wondering if the app automatically routes the path based on traffic information that it downloads or does it just goes by the original criteria.

I live in the SoCal area and my problem is trying to avoid the horror of the traffic that is I-5. Any reccomendations for a good software that will just show traffic conditions based on your gps location? (kinda like the one that blackberry has) thanks!
[Touch Pro, Fuze Themes and Apps] noellenchris:
google maps http://m.google.com/gmm

I use Garmin Mobile XT and also watch Google maps on mine...works great.
[Touch Pro, Fuze Themes and Apps] mr.jaguar:
try this. it's still in beta development, but he's gotten it pretty functional recently.

http://xdaforums.com/showthread.php?t=512630
[Touch Pro, Fuze Themes and Apps] hyachts:
Garmin Mobile XT should route around traffic if you've configured it to do so (look through the settings, I think it's called "avoidance setup" - you have to have Garmin Online access enabled). Of course, it relies on the accuracy of the traffic data and the availability of an alternate route that it calculates as being faster.

I've had it route me around traffic in NYC before, and I can't say I'm convinced it did the right thing. Of course it's hard to know how you'd have fared if you stayed in traffic...
[Touch Diamond2, Pure General] camcoh:
Is any way to use few different input keyboard and easy switch between touchflo standart keyboard and standard microsoft keyboard ?
[Touch Diamond2, Pure General] camcoh:
Nobody know ???
[Touch Diamond2, Pure General] ZuinigeRijder:
TouchLockPro has a builtin SIPChanger, where you can specifiy a different SIP for Stylus In/Out and/or Portrait/Landscape. Is that what you are searching for?