[LUCID] pull request - replace compcache with ramzswap

Andy Whitcroft apw at canonical.com
Wed Jan 6 17:36:52 UTC 2010


On Wed, Jan 06, 2010 at 09:53:06AM -0600, Manoj Iyer wrote:
> 
> This pull request removes compcache from ubuntu delta and adds the latest 
> ramzsawp (aka compcache) to staging. I built a kernel (with 
> skipmodules=true), and it is available under 
> http://people.canonical.com/~manjo/lucid/ramzswap/
> I have not tested if the latest ramzswap works the same as compcahe, but 
> from the mailing list the latest changes to ramzsawp (aka compcache) are 
> reported to work.

The first concern here would be that the name of the driver seems to
be changing from compcache to ramzswap.  However, I had a look at our
existing ubuntu/compcache version and actually if you look at the Makefile
it makes the module ramzswap also:

  obj-$(CONFIG_BLK_DEV_COMPCACHE) := ramzswap.o xvmalloc.o

Looking at the compcache support in the initramfs it seems it already
has to cope with compcache and ramzswap as names.  However, this new
version seems to have completely different use semantics.  We assume it
can be directly built as below:

    modprobe -q --ignore-install ramzswap disksize_kb="$kbytes"

but the new version only takes one module parameter:

    modprobe ramzswap num_devices=4

and relies on a new userspace tool to generate the actual devices:

    rzscontrol /dev/ramzswap2 --disksize_kb=XXX --init

so we would need to get that userspace tool as well to make this work
and update the initramfs support to trigger it.

>   drivers/staging/Makefile                           |    1 +
>   drivers/staging/ramzswap/Kconfig                   |   21 +

Finally I think if we could include this we would want to rename it over
to ubuntu for consitancy.

Overall if we do move to this version we would need to pull in the
userspace tools as a new package and we would also need to be able to
detect which version of ramzswap we have to adjust to the appropriate
semantics.

Cirtainly we cannot just blindly apply this this close to Alpha, if at
all during lucid.  I am inclined to suggest we stay with what we know
for this cycle and put this on the radar for M.

-apw




More information about the kernel-team mailing list