1

I have this crazy idea, and want to know the pitfalls of such an approach (or whether it can even work with no deadlocks.. etc).

The goal is to create an automatically expanding and contracting single swap space that provides enough capacity to match the entire hard drive. Performance isn't a big goal here. The idea is to present a buffer zone for rare occasions of over-committing memory usage.

Assuming we have 1 hard disk of 10 GB. We can create a sparse swap file via (this was derived from BTRFS swapfile workarounds):

swapfile=$(losetup -f)
truncate -s 10G /swap
losetup $swapfile /swap
mkswap  $swapfile
swapon  $swapfile

We needed to do the above because swapon doesn't allow sparse files.

So we have 2 problems here:

  1. Being sparse increases fragmentation, although this reduces performance, it shouldn't prevent it from working right?
  2. The sparse file doesn't contract in size, so we need to do hole punching (https://stackoverflow.com/a/2026015/582917 & https://unix.stackexchange.com/a/52029/56970), so perhaps we can just periodically run fallocate -d /swap or fallocate -d $swapfile (I haven't tried this yet), in order to punch holes into the swap file to make it contract after being used.

We can set vm.swappiness = 0 or vm.swappiness = 1 to make it so that processes (which are more important to me) are unlikely to use this swap.

Finally would this work with hibernation according to the instructions in https://wiki.archlinux.org/index.php/Power_management/Suspend_and_hibernate#Hibernation_into_swap_file ?

Improve this question
9
  • A) The first problem I can think of is, that if the blocksize of the fs the swapfile lives in is smaller than the memory page size(s), there may be a swapped out memory page with a lot of zeros, which will result in fallocate punching holes. If this page is to be swapped in latter what happens then? B) I believe fragmentation will become an issue pretty quickly with such an approach. C) Apart from that, I'd trust in the kernels abstraction layers that this is a valid approach.
    – Bananguin
    Dec 10, 2015 at 8:57
  • D) However, if you promise the system more swap space than your disk can deliver, I would expect nothing less than an unrecoverable system freeze in case the kernel actually wants to use a single bit more swap space than there is available on your disk.
    – Bananguin
    Dec 10, 2015 at 8:58
  • I'm not sure about A, this requires some testing, or some way of setting a blocksize of the file, or maybe the loop device? Regarding B I haven't seen any published data on the performance impact of fragmentation, so it's guess work right now. For D, that's why I think you shouldn't set the sparse file any bigger than the current hard disk.
    – CMCDragonkai
    Dec 10, 2015 at 9:17
  • For A I think you have to create the filesystem on the disk accordingly. If you introduce a loopback mounted fs into the procedure, the buffering that occurs can become problematic. If swapping occurs and a big chunck of swap space is requested a big chunk of disk space is requested which, in the case of a loopback mount, will result in a fairly large amount of memory being allocated, exacerbating the original memory shortage. I have no idea how much fine tuning of the kernel is possible to prevent this.
    – Bananguin
    Dec 10, 2015 at 9:34
  • For B, you will be fine using a SSD, otherwise it is a very well understood problem, that the number of heads in a disk is finite and small. For D, if you are not going to use the disk for anything else than swap, why even bother making the swap space sparse?
    – Bananguin
    Dec 10, 2015 at 9:34

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .