[ptero]

> If a program eats too much memory, the swap can get filled with the rest of the memory and when you go back to normal, everything is slow. Just restart the swap partition to fix it: sudo swapoff -a; sudo swapon -a

Is this true? Not impossible, but I am surprised. If true, what is this fixing? In my naive view (never studied swap management), if at the current time a page is swapped out (and by now we have more memory -- we can kill swap completely and do fine), it should get swapped in when needed next time. As there is more memory now it should not, in general, be swapped out again.

If true we are exchanging a number of short delays later for a longer delay now, which to me hardly looks like a win.

[victorlf]

I you run a very memory hungry program (like some specific scientific program), it can happen that 3GB of your memory from the browser, text editor, etc. is moved to swap. Then, when you kill the program and want to go back to normal, just changing the tab in your browser can take a long time.

By flushing the swap, you wait some time first but then it all runs smoothly. When using a hard drive and not SSD the difference is even bigger.

[joosters]

I've hit the same kind of problem before. Big task runs & eats all the memory. Later on, a login to the machine or existing shells are horribly slow until they get swapped back in.

However, swapoff/swapon only solves part of the problem - you still have binaries, libraries and other file-backed memory that were thrown out under the memory pressure and they won't be reloaded with the swapoff/swapon. Does anyone know how to force these kinds of things to be re-loaded before they are needed again?

[bratch]

It is useful in the case that you want a predictable and expected delay immediately, rather than unpredictable delays for an unknown length of time to come.

[ptero]

I get that part. I was wondering if by doing it all at once you somehow gain significantly over doing it normally. I doubt it, but prepared to learn otherwise. If it is much quicker to swap everything in maybe it is worthwhile to expose this functionality directly instead of doing hacks like swap off/on.

[joosters]

It depends on when you next need to use the system. If it is immediately after the memory hogging code exits, there's probably not much of a win.

But if you run the memory hogging program, then go to lunch, if the swapoff/swapon is triggered before you get back, you will be avoiding the delays entirely.

[BenjiWiebe]

In my experience, it makes a big difference. My swap is on a hard drive, which can handle the sequential reading of the swap quite quickly. Whereas the random accessing of it in normal use is much slower per byte.

[0xfeba]

I haven't used a swap in the past 10 years and have not noticed any problems. Is it relevant anymore?

[wolfgang42]

If you have a memory-constrained system, yes. There's a surprising amount of stuff that sits untouched in RAM for very long periods of time. I generally run fairly low-end systems, so it's not unusual for me to have a few GB in swap. (Though I just found out last week that I could buy another 4GB for $26 and free shipping, and I have to admit that was a worthwhile investment.)

[BenjiWiebe]

Yes, if you have 8GB of RAM which is enough for me 99% of the time, but you'd rather your computer slow down 1% of the time rather than crash and have to start over.

[executesorder66]

Yes. You need swap to hibernate a laptop.

[majewsky]

But is hibernate relevant? I've found suspend to be much more reliable, and good enough in terms of energy consumption (thanks to modern low-power states in CPUs).

[executesorder66]

I find it relevant. I use it to store the state my work laptop is in at the end of the day, and then restore that state when I get back to work the next work day. That way I don't need to keep it switched on when I'm not using it/transporting it.

Is there a better solution to this other than hibernating?

[0xfeba]

Duh, yes, that is needed. I don't have hibernate enabled on my laptop though, nor more importantly, my server.