Originally Posted by lma

Reading between the lines a bit, but I assume the mount package is just for "swapon -p" support? If so then http://git.busybox.net/busybox/commi...978b0864699419 might be of interest for the Fremantle CSSU (I'm backporting it to the Diablo one).

Originally Posted by atilla

there is already a thread about this : http://talk.maemo.org/showthread.php...highlight=swap

and most of us know that adding more swap to a sd cards brings absolutely nothing.
another quote:
quote by TA-t3:

Be careful with terminology, folks.

o RAM: RAM is always physical RAM. In the N900 there's 256MB of it.
o There's no such thing as 'virtual RAM'.
o Swap space: Resides in the built-in flash storage (there's 768MB of it on the N900), or could be set up on microSD as well).
o Virtual memory: This is (on Linux) the sum of swap and RAM. On the N900 it's 1GB (768+256).

Virtual memory is what the applications can potentially use (not considering some limitations added by the kernel). Virtual memory is the only thing applications know about. If you have no swap space allocated, only the 256MB physical RAM, then your virtual memory size would be 256MB. There's no such thing as 'not having virtual memory set up'. You mean _swap_ here.

o Swap space is always slower than RAM. Maybe in the future this could change, when/if some of the stuff being worked on in the labs manifests itself. Then maybe we'll have RAM, SD cards, USB sticks, other mass storage, all built from the same magical, non-volatile, super-fast stuff.

o Adding swap will not make for a faster device, only for a device which can sustain more applications running at the same time, or using more data, without going down in flames. There was a myth, for a while, that the N800 and N810 would be faster if you enabled swap space. This was only in the imagination - I tested this. And there's no rational reason it should be faster, except in very carefully thought out scenarios that won't happen with normal use.

o Adding excessive amounts of swap _will_ make your device slower, eventually. Particularly if you keep your applications (e.g. browser) running at all times.
__________________

Originally Posted by Tigerite

Thanks for sharing the swapon.gz, I've been trying to get the priority option to work with no success (even went to the trouble of downloading the Easy Debian ext2 and mounting it, but that one didn't have a -p option either).

However, I find it easier (and probably less risky, as it's possible that the SD card isn't ready when rcS-late is run) to edit /etc/event.d/rcS-late to use /sbin/deb/swapon -a, i.e.

Code:

 /sbin/swapon -a || echo "Failed to enable paging partition."

(NB, /sbin/ might not be there, I'm working from memory as I've already changed it) to:

Code:

 /sbin/deb/swapon -a || echo "Failed to enable paging partition."

..and then edit /usr/lib/genfstab.awk so that the swap partition is mounted with pri=1, i.e.

Code:

start == 1 && $6 == 82 {
 printf "%s none swap sw 0 0 \n", $1
}

becomes

Code:

start == 1 && $6 == 82 {
 printf "%s none swap sw,pri=1 0 0 \n", $1
}

.. then /sbin/deb/swapon -p 1 /dev/mmcblk1p2 (or whichever partition the swap is on) in a custom event.d script which is run at a later time.

I've been experimenting with compcache, using disksize of 128M (rather than memlimit) and then setting the ramzswap priority to 2 (so it is used first), leaving the striped file-based paging file for when it is used up. Unfortunately I think the swap free notify patch that I modified to work with Nokia's swap_remap isn't completely right, as I'm getting lots of "BUG: scheduling while atomic: kswapd0/15/0x00000000" in dmesg - unless that is a direct result of the striping, of course..