Re: [ANNOUNCE] COMPCACHE on kernel-power (now with notifications)
 

It's really nice that you have finally taken on porting compcache, I was amazed nobody did it for the N900, I did it for the N8x0 and the performance improvement was very noticeable.
In the N8x0 world, having 128 MB of RAM we are using disksize=96 MB by default. As you know, disksize is not the ram used by compcache, having a compression ratio of about 1/3 usually, so in the N8x0 we usually have about 50 MB of swapped ram and 20 MB of ram used for compcache.
So, I find very curious that you are using such a low value when you have 256 MB and a much faster cpu. Really, you should be able to use disksize>128MB with no problems, so may be there is some other cause, may be too much locked ram?
Well, having a look at your sources, I'd recommend to try the same changes I did in ramzswap_drv.h , increase max_zpage_size_nobdev to PAGE_SIZE/8*7, and do not setup a backing device (the code is really inefficient).

Re: [ANNOUNCE] COMPCACHE on kernel-power (now with notifications)
 

Just for the record: i ALWAYS had reboot issues when enabling ramzswap device, regardless of disksize. Just uninstalled speedpatch and batterypatch (like freemangordon suggested multiple times), and tried again (propbably for the 10th time now). At least it created and initialized the device now. So now up to testing with freemangordon's proposed proc and sys values.

I used colin.stephane´s kernel packages btw, and moved swap to /dev/mmcblk1p2 (512MB size).

Remaining issue is that swapoff /dev/mmcblk0p3 takes ages and often returns the message "swapoff: /dev/mmcblk0p3: Cannot allocate memory".

Question: can we use memlimit_kb instead of disdksize_kb and provide /dev/mmcblk1p2 as backing swap, disabling swap on /dev/mmcblk0p3 as usual?

Re: [ANNOUNCE] COMPCACHE on kernel-power (now with notifications)
 

Do not use backing swap, it is EXTREMELY SLOW, second swap is much better in terms of performance. Of course it is much better to be on SD card instead on internal flash.

Re: [ANNOUNCE] COMPCACHE on kernel-power (now with notifications)
 

Thanks for your advices, unfortunately looks like Maemo 5 is much more memory hungry than Maemo 4. For some reason I still not understand, with swap sizes > 96 M, once compcache swap becomes full, the system becomes totally unresponsive. It looks like someone is constantly moving pages in and out from swap. Most probably I will look at the issue when current CSSU campaign ceases.

Re: [ANNOUNCE] COMPCACHE on kernel-power (now with notifications)
 

That's also solved.

Re: [ANNOUNCE] COMPCACHE on kernel-power (now with notifications)
 

so after more tests and long uptimes i've finished up with
swappiness=30
page-cluster=5
vfs_cache_pressure=110
dirty_background_ratio=5

disksize_kb=81920

Next step is to test it with BFS...

Re: [ANNOUNCE] COMPCACHE on kernel-power (now with notifications)
 

Some sort of OT question, but I do not get it:
what is the difference of backing swap and second swap?

I do understand that enabling another swap (after the first) will just give some more amount of swap, if first one overflows. Right?
And the prority of first enabled swap is always higher (or use swapon with option -p 32767, enhanced busybox).

So where is the difference of backing/second?

Re: [ANNOUNCE] COMPCACHE on kernel-power (now with notifications)
 

Backing swap is a feature of Compcache. Compcache has some code to send pages that compress rather badly to an user-chosen 'backing' swap, which in fact doesn't differ from normal swap space in any way. By using a backing swap, you can get more out of your RAM since only the good compressible pages will be in-memory. However, it appears that the code used to do this is rather inefficient, and therefore it is recommended to not use this feature.

Setting a second swap behaves like you would expect it to do: when the first one gets full, the second one will be used (if you haven't changed the swap space's priority, that is).

Re: [ANNOUNCE] COMPCACHE on kernel-power (now with notifications)
 

Thanks for that bit. Is there a way that busybox' swapon would include swap priorities in a future update? That way we could omit the swapoff/swapon workaround.

EDIT: There's the mount package, supportingly with priority support for swap.

EDIT2: Said mount package has unmet python dependencies on my device. Bummer.

Re: [ANNOUNCE] COMPCACHE on kernel-power (now with notifications)
 

Ok, so let's bump the relevant thread

I think you are wrong and your fears are irrational (no offense intended), and I think they are causing more harm than good, for the reasons I'll lay below:

First, effectively, there is a spin lock involved in each stat64 operation, but why is it there? Because compcache 0.6.2 supports several ramzswap devices, and needs to protect the stat operations of one device from the others.
If you look at the compcache 0.5.5 sources, you'll see that there is no spin lock at all, and what is more, the mutex held in ramzswap_write() is freed before all stats operations.
So, having just one ramzswap device, and I can't see why anybody could want to have more than one in the N900, there can't be slowdown at all.

Second, even if you have more than one ramzswap devices, all stat operations are just integer additions. How much will have one process to wait for another to perform an integer addition?. A microsecond?, and that's within a page operation which requires either compress or decompress no less than 4 KB.

Third, you talk about swap trashing, but not having stats prevents anybody from knowing what's going on inside ramzswap.
Finally, you recognize we have much bigger issues here, with a much bigger impact than a few microseconds from a lonely spin lock, where we would benefit from any information available to find and fix them. The more peope is able to gather information, the more chances that this gets fixed. By asking me, and everybody else, to build ourselves the modules, you are just putting blocks in the road.

So, I strongly advocate for enabling stats, which we have been using in the much slower N8x0 with no problem since I started this project. Believe me, it is a feature you want there.

You say that swap trashing happens when ramzswap is full but that doesn't match my observations. I still don't know if it is swap trashing or constant page swapping (no stats), or what kind of memory fighting is going on, but it happens much before ramzswap is full.
With ramzswap active and some memory pressure (just microb and opera), I observe that:
- the amount of free memory is much bigger than with normal swap, I've seen up to 100 MB free, while with normal swap it is around 5-10 MB free
- the amount of free memory constantly oscillates against the used memory with a period of a few seconds, while the swap consumed remains more or less constan. The oscillation can be as big as 10 to 100 MB, it seems the bigger the ramzswap size, the bigger the oscillation.
I have never seen anything like that happen in the N810.
It could be the changes Nokia did into the swap code (haven't looked), or it could be memory mapping of some big files, or it could be buffers/cache pressure, or the Xorg heap (just guessing), but it seems that, as memory used for ramzswap grows, it puts pressure into freeing memory, but as free memory grows, something puts pressure for using that memory a while later, repeating a cycle.
This requires more investigation.

And that's a reason for not being more memory efficient??? Certainly I don't understand you here.