Seems you beat me to the punch, way to steal my mojo. I have been running these settings since this morning when I posted. I have just come back from a 3 hour motorbike ride.


The whole time I had running:

• marble maps, making a track with GPS
• 2 browser windows, one with TMO open.
• conversations
• OMP playing an MP3
• Cloudgps briefly
• xterm
• and I was snapping photos with camera-ui2 and blessn900
• I also answered some phone calls

I am running CSSU-T+KP50@250-900(SR vdd1+2).


All in all I have not seen any lagz, in fact everything seems like a fresh boot 'normal'. I think this is a definite improvement from 'as soon as ramz full, n900 lags to ****'. As to whether it is a complete improvement? I do not know yet and this is not even using the swap on uSD which in theory should make things even better.

My proc/sys/vm/:

I am not going to lie, I do not understand all of the settings in the VM.

You will notice is swappiness is so damn high. My notion being that with reduced ram (due to ramz taking up so much space) the device is going to swap, there is no fighting it. So to use swappolube style settings will not work. They angle for swap little and swap rarely. So if we are going to HAVE TO swap then by christ we are going to swap to the mutha ****ing MAX with only programs being swapped in/out, no VFS cache.

VFS_cache_pressure > 100 tells the VM system to dump file system caches whenever it can (more or less). Reading from our RAM and flash media is mega fast, so we do not really need any file system caches so chuck em, chuck em as fast as you can. I think you can see the effect of this. With VFS_cache pressure so high (although it could go higher) I can actually see the amount of space used in ramz swap going up and down. This suggests to me that ramz space is properly being churned through, i.e. there is no junk in there just good tasty stuff that we need swapped in and out. Before I would observe ramz filling, the lags would start then I would give up.

echo 32 > /proc/sys/vm/min_free_kbytes sets the amount of free space for allocating big chunks if they happen to come along. Screw it, I need every goddamned KB. So it has been reduced from 4MB of waste to 32KB of waste.

The rest of the stuff is cruft left over from swappolube and some stuff by the guy in 'massive IO improvement under heavy load'. Particularly the parts about nr_requests and dirty ratios.

This is after about 8 hours of use:

Ramz ain't even full!

Next I shall run 128MB Ramz and see what happens.

@vi - I'm willing to give this another go - any chance you could share your pre-compiled kp50 binaries or .deb files modified with compcache?

w00t, meh first wikeh

Any idea what is the rationale behind "echo 4 > /sys/block/mmcblkN/queue/nr_requests" in the context of compcache? As I see it, that setting will have a major impact on device responsiveness during heavy i/o, leading to watchdog kicking in some corner cases.

By jove FMG. You have done it.

At first I was convinced 128MB ramz was futile. I could not get past opening opening 6 webpages + opera (1 web page) without the system grinding to a halt.

Now I have:

6 webpages + opera (1 web page) + conversations + image viewer + conky + sygic mobile + an SMS + modest + xterm + disk-useage + angry birds.

Gives this:

There is a teensy bit of lag (100-200mS) when switching between windows however page scrolling seems smooth when you get there. Angry birds for example is fully playable (or as playable as AB is)I have yet to try receiving a call under this load or try some easy debian programs.

At this point I can say RAMZSWAP RULEZ. (this statement is subject to further testing)

As for nr_requests, I thought that by keeping the que short, things would be eligible for shunting out to swap ASAP. Kind of like keeping page cluster low. Alas it seems to not be the case.

As I said, I do not fully understand all of this stuff. I am still chimping in the dark.

I'm running this right now. The performance is frakkin' insane. App response times (not including app launch, which is slowed down by loading programs into compressed RAM) are improved way, way more than a modest overclock! (I disabled overclocking to test actual performance gains)

I'm the chappie who threw together swapset. I've tried the above settings with it and it works awesomely. The settings caused resets under load for me at first, but I realised I still had a very old set of settings in my /etc/default/kernel-power file, and after dumping those all seems well. I might try overclocking again to see if I can get the best of both world...but awesome job for that bit of tuning. I stopped looking at swapset when I realised compcache had awful performance with my current settings, but I might go back to it now and have it automatically swap between vm settings based upon whether you have compcache in use. Might have to add a conflicts with swapolube though...or perhaps just override it? Hmmm...

I'm using swapset (64MB ramz, 512MB on SD). With _vi's settings,the pig now flies faster than a damn V2. Impressive! /darthvadervoice

Hey,

my experiences are not that good.
Tried around with vi_'s settings, went back with swappolube to ddfault settings (yes before also esets). But it is still not as snappy as with just swap on SD. App launching and task switching is just fine now again. With ramzswap enabled always a bit behind, subjective.
Tried around with those parameters, but to no avail (some of them I have nfc what they do).

My swap usage is quite higher than vi_'s.
Maybe swap usage higher than ramzswap size is the problem?

Furthermore I noticed with these settings a huge amount of data written on SD swap: 1,5GB a day. Causing my swap refresh to become activated twice a day. where it normally is at least 1-2 days.
And the battery felt a bit like a looser (estimated 1000mAh).

Just my experiences. Hope we can get it to run for everybody easily. and gain RAM. speed, ...

BTW: mr_jrt, i think you have small bug in swapset.
if -s checks for file size -gt 0. but /dev/ramzswap always returns 0
so I modified a bit (also timeout will not activate) and this runs in my multiboot (so I may decide to activate or not via keyboard).

In the last two days i've been using these settings - the device responsiveness is great, but i found a few new issues with it since (i'm not sure it is related):

there seems to be some problem with the tracker process - it stopped working - the output i got from its log when i restarted it (/root/.local/share/tracker/tracker.log):
----
29 May 2012, 23:03:07: Tracker-Critical **: Indexer couldn't disable all volumes, Method "VolumeDisableAll" with signature "" on interface "org.freedesktop.Tracker.Indexer" doesn't exist

29 May 2012, 23:03:07: (null)-Warning **: Attempt to disconnect from signal 'Finished' which is not registered
----
I removed its installation and installed again and now i can see that it starts ok, trackerd and tracker-indexer processes exist now, but i cannot see images in the photos application, no videos/music and internet radio files in Open Media Player, and my email widget shows "no configured account" if i open it i can see the email account as usual in the email application (i've waited until after the database refresh counter shown when photos application is launched - and still - no media files can be seen with these applications).

The only 2 changes i made in the past few days was to start using the ramz partition and change these settings, however this might be just a co-incidence. i've read in few places that there might be a file limit for the tracker, but wasn't able to fix it.


Anyone had similar exprience/knows the cause for this and how to fix it?