Issue 67  has been merged into this issue.

I'm aware of this rzscontrol incompatibility and Please do not use compcache driver from upstream Linux kernel. It lacks lots of changes which were done after that merge.

I will soon be releasing a new version of compcache that does not require rzscontrol and has many more improvements. I guess it will take significant amount of time to sync all these changes with mainline kernel.

For the new compcache version, you can checkout directly from repository:

    hg clone https://compcache.googlecode.com/hg/ compcache

The README file in the source root contains information on how to use it. Some of its features include (see Changelog for details):
 - Devices are now called /dev/zram<id> (<id> = 0, 1, 2 ...) instead of ramzswap since they can now handle any kind of I/O and not limited to use as swap.
 - Replaced ioctls with sysfs interface. So no need for separate tool like rzscontrol.
 - Percpu stats and buffers for improved scalability
 - Lots of other cleanups, minor fixes.

I could not spend much time testing it, so not releasing it as a separate tarball. Also, I will be out of this project for next 1 month approx., so expect delays for any replies/fixes etc.

Thanks! I'll check it out!

Works very nicely! Will you post that to lkml?
Great idea to make it usable for /tmp as well!

I posted it to lkml: http://lkml.org/lkml/2010/8/9/226
But it's getting lot of resistance from kernel developers. Lots of things yet to be worked out.

I see. But they seem to be lots of minor things and from a very positive stand point. I think they generally all like the code. It's just that they are (rightly) afraid there will be a lot of adoption and use of zram and they want it to be well maintainable later.

Yes, most are minor things and that's positive side to it. But unfortunately going by all those suggestions will be time consuming and it will be quite some time before I can continue work on this project again. The second child project, zcache, is also expected to take a long time before mainline merge: http://lkml.org/lkml/2010/7/16/161

Yes, on zcache there seems to be more work to be done. But still this is all pretty impressive high end kernel work. And the code is good. It could be merged right away I guess. But I think both will be used a lot. It's not like writing a driver for some device nobody uses, this is more like tmpfs. Everybody might end up using these.
I've been wondering if it would be possible to use the fs of tmpfs on top or zram - sort of a ztmpfs, because I have a strong feeling a lot of the code of ext is unncessary for a ram fs and just slows it down. But if this was easy to be done someone probably would have done it a long time ago. I'm amazed I can't find any major criticism.

I mean not zcache itself, but cleancache.

rzscontrol is not required fir zram (to be released sometime). Closing the issue.