I believe that something strange is going on with my swap / hardware / drivers.

I'm trying to increase the swap size by swapoff, lvresize, then swapon again.

When I did swapoff /dev/swapdev, the command took 8mins 19seconds to move about 3.5GB of swapped pages into memory.

I ensured that my free RAM was greater than the swap usage before running swapoff, and this stayed true while it was running.

I have a Intel Core i5 laptop with SSD HDD. The processor was at less than 10% before swapoff, and when I checked in, swapoff was using 70%+ CPU.

There was nothing interesting in the journal the whole time.

Here's approximately how long I'd expect it to take to shunt 3.5G from disk to memory:

$ time dd if=/dev/urandom of=/tmp/del bs=1M count=3500
3500+0 records in
3500+0 records out
3670016000 bytes (3.7 GB, 3.4 GiB) copied, 23.7288 s, 155 MB/s

real    0m24.789s
user    0m0.000s
sys     0m22.743s

I'm running Linux svelte 4.9.53-1-MANJARO #1 SMP PREEMPT Thu Oct 5 15:11:15 UTC 2017 x86_64 GNU/Linux

Any reason that the command would take so long? This could be part of a larger issue, but this is the first thing that I can definitively point at which looks strange.

  • 1
    It may be useless after the fact but the -v flag may be useful going forward. Nov 9 '17 at 9:28
  • 1
    It seems you should be happy with 8minutes,as this question complains about 4 hours, though that was for a rotating drive. The answers to that question have some explanations, and in particular this answer provides a speedup.
    – meuh
    Nov 9 '17 at 9:36

You're missing what swapoff really does.

Retiring swap space on a running machine, which is swapping, is extremely complex. 3.5G in 8min is likely very fast + is working as expected.

Running swapoff doesn't just simply move code off disk into memory.

Once you're swapping... well... you're swapping, which means your OS is starved for memory + you have disk i/o to your swap device + disk i/o to your other file systems + maybe even the OOM (out of memory killer) starting to run + then process thrash of OOM'ed processes restarting, if watchdogs or systemd auto restarts are involved.

If your system is swapping, that means swapping is the only thing keeping your system alive.

If you kill swap space, then your system can't use swap space anymore, so now your OS has to load code of normal filesystems + evict code when memory is exhausted + then rather then pulling code off fast swap space via optimized, raw disk reads, all your code has to come off normal filesystems, with directory walks. This is far more resource intensive, than pulling from swap space.

When you do a swapoff on a system that's swapping... usually you'll end up in a situation where this process will take hours + sometimes machines will crash.

If you have to retire a swap device for some reason, best to first create a secondary, filesystem based swap space + do a swapon for this new swap space, then do your swapoff on the old swap device.

If you take this approach, your system will always survive.

  • 2
    The thing is, I closed chrome and thunderbird and ensured that my free RAM was greater than the swap usage first. I should have mentioned this in the question. I wouldn't ask it to do the impossible.
    – Tom Hale
    Nov 9 '17 at 15:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.