13

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.

Improve this question
2
  • 1
    It may be useless after the fact but the -v flag may be useful going forward. Commented Nov 9, 2017 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. Commented Nov 9, 2017 at 9:36

1 Answer 1

Reset to default
12

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.

Improve this answer
2
  • 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. Commented Nov 9, 2017 at 15:39
  • 1
    False: “If your system is swapping, that means swapping is the only thing keeping your system alive.” Linux will proactively move seldom-accessed anonymous pages into swap to free up more physical RAM to cache the file system. This happens even if your system is not under memory pressure at all — swapping will occur even when MemAvailable is a large fraction of your total physical RAM. This is by design, as physical RAM holding seldom-used pages is wasted and is much better put to use as cache to speed up file-system accesses. Commented Apr 30, 2024 at 22:11

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.