ramzswap not useful without userland

[GoogleCodeExporter]

Basically, I'm a little disappointed that we have to run a userland tool to 
bring up the ramzswap devices.

Would it be possible for ramzswap to initialize and use a standard, default 
ramzswap (for "embedded systems") in RAM (the same 25% of memory defaults 
would be fine) such that when you boot, you ALWAYS have some kind of 
compressed swap and at least one swap device initialized?

Extra swap devices on backing storage could then be added on top using 
rzscontrol, or the on-boot one deconfigured and reconfigured.

Original issue reported on code.google.com by mwsea...@gmail.com on 27 Dec 2009 at 2:24

[GoogleCodeExporter]

> Basically, I'm a little disappointed that we have to run a userland tool to 
bring
up the ramzswap devices.

getting rzscontrol to run on embedded system is painful? 

Original comment by nitingupta910@gmail.com on 28 Dec 2009 at 8:12

[GoogleCodeExporter]

No but, I thought maybe like you can set "embedded system" options for squashfs 
to 
tweak its behaviour, maybe ramzswap could initialize a swap device without a 
userland 
tool at all, it used to be able to do this before rzscontrol (module arguments) 
but a 
default compressed swap device might be very useful.

Original comment by mwsea...@gmail.com on 28 Dec 2009 at 3:09

[GoogleCodeExporter]

> Would it be possible for ramzswap to initialize and use a standard, default
> ramzswap (for "embedded systems") in RAM (the same 25% of memory defaults 
> would be fine) such that when you boot, you ALWAYS have some kind of 
> compressed swap and at least one swap device initialized?

You anyway have to issue 'swapon /dev/ramzswap0' to bring up this swap. With
rzscontrol its just a matter of adding on more (rzscontrol) command to your 
startup
script.

Original comment by nitingupta910@gmail.com on 21 Jan 2010 at 2:07

[GoogleCodeExporter]

I could not really justify for an "embedded" mode obviating the need for 
rzscontrol
utility. It adds some unnecessary stuff to code too. Also, there is only one 
person
voting for this issue. Sorry :(

Original comment by nitingupta910@gmail.com on 22 Jan 2010 at 12:59

• Changed state: WontFix

[GoogleCodeExporter]

I think the basic difference is that "swapon" can be contained in busybox, but 
rzscontrol is a whole seperate utility. Using precompiled userlands (which you 
do not 
want to change too much for embedded reasons) you could always bring up a 
simple swap 
device without much effort..

If you load the module (or build in) then there is a certain number of swap 
devices 
made by default (default = 1). Is it really too much code to make the default 
swap 
size on this precreated device a kernel option like squashfs "embedded" 
options? That 
way you can have a default 25%-of-RAM swap device which you can swapon by 
editing 
fstab..

Original comment by mwsea...@gmail.com on 22 Jan 2010 at 7:05

[GoogleCodeExporter]

> I think the basic difference is that "swapon" can be contained in busybox

oh, I was missing the point that swapon can be part of busybox itself (shows my 
lack
of experience in embedded). Now it seems to make sense to have 1 device
autoconfigured with defaults, as you suggested. I will look into this.

Original comment by nitingupta910@gmail.com on 23 Jan 2010 at 1:17

• Changed state: Accepted

[GoogleCodeExporter]

The changes have been committed to hg: Now you can initialize first device
(/dev/ramzswap0) during module load, without using ramzswap. For e.g.:

insmod insmod ./ramzswap.ko disksize_kb=20000

this will initialize /dev/ramzswap0 with given disksize. Similarly, you can do:

insmod ./ramzswap.ko backing_swap=/dev/mapper/vg_vflare-lv_swap

You can reset, re-config any device later using rzscontrol, of course.

Original comment by nitingupta910@gmail.com on 24 Jan 2010 at 7:03

[GoogleCodeExporter]

Original comment by nitingupta910@gmail.com on 24 Jan 2010 at 9:29

• Changed state: Fixed