Notices

Originally Posted by Estel

For most, (me including), ramzswap works OK, but doesn't offer any noticeable benefits.

As for ereswap, of course, it provides benefits - after all, "virtual" swap is a gain of only half of ramzswap size (so, for 64 MB ramzswap, You "gain" 32 MB at cost of CPU power), so fragmentation of "real" swap is only delayed.

Originally Posted by lma

Anyway, I was basically wondering whether fragmentation is a significant issue on RAM and whether ereswap-like recycling would make sense in that context. I practically never hit "real" swap (even though I've left it enabled just in case with a lower priority) so that's not a real concern.

Originally Posted by Estel

@lma
For most, (me including), ramzswap works OK, but doesn't offer any noticeable benefits.

Originally Posted by Hurrian

ramzswp does work on the N900, albeit with questionable benefits. I tried a disksize of 64MB, and ended up with massive swap episodes (bigger than the usual ones, and usually resulting in omap-wd rebooting the device) with just the music player and MicroB running.

Perhaps more investigation into kernel tunables may be needed, if it really does benefit low-memory devices trying to run full Linux desktops.

Originally Posted by Estel

@lma
Just keep in mind that editing rcS-late by hand invalidate it for using adjust-rcS-late and update-rcS-late - yet, it's not a big deal, as if You know how to edit rcS-late by hand, You actually don't need those two scripts They're mean to "automagically" update rcS-late, saving it from users doing manual changes to file, that is critical for boot process.

/Estel

Originally Posted by peterleinchen

Estel, during fiddling with multiboot, compcache and recovery shell I found that we do not need to edit system critical files (rcS-late) directly, but we may enable SD swap / disable eMMC swap later safely with script in event.d:
start on started ke-recv is early enough, no data is written to eMMC swap at this point (256MB mem is too less, but to this point sufficient ).
So I modified my scripts to enable ramzswap (priority 1), then SD swap (priority 0) and the disable eMMC swap (priority -1). I do not see any boot delays, except enabling of swap (swapon -a), but this should not consume much time (less than we can measure).
Just for info,

Originally Posted by peterleinchen

So I modified my scripts to enable ramzswap (priority 1), then SD swap (priority 0) and the disable eMMC swap (priority -1).

Originally Posted by peterleinchen

Estel, during fiddling with multiboot, compcache and recovery shell I found that we do not need to edit system critical files (rcS-late) directly, but we may enable SD swap / disable eMMC swap later safely with script in event.d:

Originally Posted by Estel

The best thing is to disable eMMC swap completely via /sbin/swapoff <location of emmc swap>, but anyway, good find. If it's done on point, when no data is written to swpa at all, it shouldn't make any difference in booting time.

Still, do we gain anything by it? If our script is screwed, we will end without swap = system still won't boot, like with screwed settings in rcS-late. Either way, recovery console (in any flavor, be it backupmenu's one or any other) is needed to fix that by hand (or via backup).

I think it's similar effort to (via recovery console) "rm /etc/event.d/custom-screwed-script", and "cp /pah/to/rcS-late.backup /etc/event.d/rcS-late". In fact, when talking about practical side (bootable/unbootable), any script dealing with swap in such way is "critical" to the system.
/Estel

Originally Posted by Hurrian

The point was to speed up boot by streamlining the swap selection process (and avoid activating eMMC swap then swapping-off a few seconds later).

It should be safe to throw in "if /lib/modules/current/ramzswap.ko insmod /lib/modules/current/ramzswap.ko disksize_kb=65536 swapon -p 5 /dev/ramzswap0" before MMC-device swap detection happens.

However, I would strongly suggest testing out ramzswap options before putting it in. The results people are getting are wildly variable. If the pre-Fremantle guys say it's good, we need to get our kernel tunables just right (avoid everything getting put into ramzswap, and hitting swap+cpu hell, etc)