maemo.org - Talk - [DISCUSS] SDCard Swap Partition Methods..

maemo.org - Talk (https://talk.maemo.org/index.php)

- Maemo 5 / Fremantle (https://talk.maemo.org/forumdisplay.php?f=40)

- - [DISCUSS] SDCard Swap Partition Methods.. (https://talk.maemo.org/showthread.php?t=84296)

Re: [DISCUSS] SDCard Swap Partition Methods..

Maybe I've overlooked information and/or threads on here, but a couple of weeks back I did a reflash and decided on spending max. 2 hours on running the swap on the microSD. Bottomline, I couldn't find a helpful guide and/or tools to achieve this so I gave up. If the result of this thread would be a comprehensive guide, working for most users, I would be really glad!

Re: [DISCUSS] SDCard Swap Partition Methods..

Quote:

Originally Posted by Hurrian (Post 1207737)

A better solution would be to replace swapon -a with the 'swapmicro' script posted somewhere here on TMO, which detects swap partitions on the microsd, and if it is available, uses that and doesnt bother with emmc. Otherwise, if there's no swap on microsd, it simply runs swapon -a.

I'll post my edits to rcS-late when I get back home.

It's very good idea - I will gladly use it myself, sounds like best bullet-proof solution for this.

@peterleinchen
As I've written, way of doing ti via /etc/event.d/ script isn't bad at all, but it got one drawback - boot time is considerably slower, as Maemo need to enable eMMC swap first, then, via Your script, enable microSd swap, and disable eMMC swap. As - at this point - some thing are already swapped (most likely, You run event.d scripts after starting hildon-desktop), they need to be moved from eMMC swpa to microSD swap.

As for using microSD swap together with eMMC swap, I don't recommend it, even with higher priority for microSD swap - it's still "in use", which creates (less, but still), I/O rade with things from optFS. Also, I'm quite sure, that using loopback file for swap is considerably slower than native swap - as it's with ED loopback image or native partition.

@BertvanDorp
5 minutes guide to using swap on microSD:

1. Reformat microSD card to contain linux type swap partition, by any tool You prefer (linuxbox/linux LiveCD via GUI tools, or on-device via command line, or on-device via Easy Debian with GUI tools, or...).

For this example, we assume You got 2 partitions on microSd card - first one is regular vfat, and 2nd one is linuxswap.

2. Use any method mentione din this thread to make device into using swap on /dev/mmcblk1p2 (you can edit /etc/event.d/rcS-late as suggested by me, or prepare script put into /etc/event.d folder, or wait for Hurrian to post his script and mix it with my way, or...).

You're done.

/Estel

Re: [DISCUSS] SDCard Swap Partition Methods..

how to increase available ram? cant we get atleast 200 from 256?

Re: [DISCUSS] SDCard Swap Partition Methods..

Quote:

Originally Posted by Mohammed Muid (Post 1208389)

how to increase available ram? cant we get atleast 200 from 256?

o0

Dafuq?

I don't think you understand what RAM is, what RAM is for or indeed how it is utilised under linux.

Re: [DISCUSS] SDCard Swap Partition Methods..

listen. I know that u have knowledge on these bt android also has a linux base kernel. Flashing differnet kernel increases the available RAM. I have a galaxy s. When i first bought it it had 356md RAM free out of 486. Then i rooted my device. Flashed some custom ROM and kernel. And installed some tweaks. Now i get 412 available which obviously makes my device faster.

Re: [DISCUSS] SDCard Swap Partition Methods..

No. It doesn't. Really, just trust me on that (tm). And see this:
http://en.wikipedia.org/wiki/Random-access_memory

http://ffhacktics.com/smf/index.php?...ach=5741;image

Re: [DISCUSS] SDCard Swap Partition Methods..

Quote:

Originally Posted by Estel (Post 1207247)

So, best way, if You're absolutely sure that it's what You want, is to edit /etc/event.d/rcS-late, replacing line:

Code:

swapon -a

...with

Code:

swapon /dev/mmcblk1p2

Or, you can try swapset. I use it and it works pretty fine.

Re: [DISCUSS] SDCard Swap Partition Methods..

Quote:

Originally Posted by Mohammed Muid (Post 1208389)

how to increase available ram? cant we get atleast 200 from 256?

kill Xorg, run everything in text mode :D

Re: [DISCUSS] SDCard Swap Partition Methods..

Code:

    cmp -s $tmp_fstab $fstab || cp $tmp_fstab $fstab

    rm -f $tmp_fstab



    if [ $ACT_DEAD -eq 0 ]; then

      drivelist=$(sfdisk -lndq /dev/mmcblk1)

      swapmicro=$(echo "$drivelist" -n | grep Id=82 | awk '/mmcblk1/ {print $1}')

      if [ "$swapmicro" ]; then

        /sbin/swapon $swapmicro

      else

        /sbin/swapon -a

      fi

      # Setup lowmem module

      echo 32768  > /proc/sys/vm/lowmem_deny_watermark_pages

      echo 98304  > /proc/sys/vm/lowmem_notify_high_pages

      echo 131072 > /proc/sys/vm/lowmem_notify_low_pages

      echo 1024   > /proc/sys/vm/lowmem_nr_decay_pages

      # Exclude some UIDs from memory allocation denial.

      # 30000 is messagebus, 30001 could be used by Matchbox

      echo "30000 30001 30002 30003" > /proc/sys/vm/lowmem_allowed_uids

    fi



    mount_home && HOME_MOUNTED=1

As promised, here's the modification to /etc/event.d/rcS-late.

Re: [DISCUSS] SDCard Swap Partition Methods..

Quote:

Originally Posted by Mohammed Muid (Post 1208389)

how to increase available ram? cant we get atleast 200 from 256?

Free RAM is wasted RAM. Ideally you want 100% of RAM used (by applications/cache/buffers) and 0 swap usage. Swap is horribly slow and should be avoided at all costs (this sentence applies not just to N900, but all linux systems -- and this is why most Android devices don't use swap at all).

Unfortunately, N900 and Maemo5 as it runs on N900 simply can not function without swap. N900 really should have 512MB minimum to run smoothly, but that SoC configuration was not available to Nokia at the time N900 design was finalized, from what I've read.

Different kernels may affect RAM availability as a result of different compiled-in options or optimizations. On N900 virtually everything that is nonessential is compiled as a module, meaning it does not get loaded unless it actually gets used. Unused modules don't use any RAM.

There are recent discussions on LKML about optimizing swap for flash media, batching writes to align to erase-blocks, etc. which would greatly speed it up (similar, for example, to Btrfs in SSD mode). But this doesn't exist in our old kernel and may never exist for us if it's something that can't be backported easily.