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.