[CoconutPilot]

Swap was a great idea, but its time is gone. Swap doesn't make sense anymore, hard drives have not scaled and kept up with the improvements in RAM.

In the Pentium 1 era EDO RAM maxed out at 256MB/s and hard disk xfer was 10MB/s. Common RAM size was 16MB.

In today's era DDR4 maxes out at 32GB/s and hard disk xfer is 500 MB/s. Common RAM size is 16GB.

RAM xfer rate has grown is 320x. RAM capacity has grown 100x. Disk xfer rate has grown 50x.

Swap is no longer a useful tool.

[Dylan16807]

The purpose of swap is not running things out of it. The purpose is shoveling unused data out of memory. And for that it doesn't need to be particularly fast.

Swap has a lot less purpose in a world without memory leaks and extraneous functions. But in practice it's quite good at getting several gigabytes of unnecessary data out of the way, so ram can be used properly.

Swap, well-used, should only take up a few percent of the drive's bandwidth.

[tmyklebu]

> The purpose of swap is not running things out of it. The purpose is shoveling unused data out of memory. And for that it doesn't need to be particularly fast.

You can't detect a priori whether data is "unused." If you guess wrong a few times in a row, you get the familiar pattern where your Linux box is unresponsive to everything and needs to be bounced.

If you could detect whether data is rarely used, swap still isn't necessary. Applications can mmap() a file and use that region for "rarely used data" if such is known in advance.

Extraneous functions should be backed by the executable in the common case. In the JIT case, they probably won't be JITted anyway.

I still think the OOM killer is less intrusive than swapping to disk. It kills some, but not all, of the processes on the machine get killed. The system pretty reliably comes back to life in less time than it takes a human to diagnose the problem and bounce the system. As a bonus, no human needs to get involved.

[Dylan16807]

> Applications can mmap() a file and use that region for "rarely used data" if such is known in advance.

They could, but that's a lot like just making swap be manual.

> Extraneous functions should be backed by the executable in the common case.

I don't mean the code itself, I mean all the data it builds up for something that isn't needed.

[tmyklebu]

> They could, but that's a lot like just making swap be manual.

Sure. Isn't that a good thing? Rarely-used data can be swapped out to storage allocated for the purpose, as you desire, and too-large working sets don't have to hose the machine.

> I don't mean the code itself, I mean all the data it builds up for something that isn't needed.

I guess I don't often run programs that waste large amounts of memory for no reason. Either my working set fits or it's too large, and swap only matters if it's too large.

Is Java the typical beneficiary here?

[lesserknowndan]

This reply was a much better explanation than the entire original article, or to summarize “Because memory leaks”.

[adrianmonk]

Swap may or may not be obsolete, but I don't find this particular argument on the subject convincing.

When dealing with swap, continuous transfer rate of the hard disk is not the relevant metric; seek time is.

In my experience, when the system starts needing to read a lot of pages back in from swap, it tends to do so in more or less random order. It reads a small amount of data, then it seeks to a new position, then reads another, and so on.

(I also find the argument unconvincing for a separate reason: I think hard drives are somewhat obsolete. Even my home system has flash instead of swap. And flash has a massively better seek time.)

[mort96]

There have been times when I have needed to do something which requires more memory than is physically available on the machine. Without swap, those tasks would have been literally impossible to do without upgrading the machine. With swap, it just takes a little longer - but still much shorter than it would take to order more RAM sticks.

One of those times was on a 512MB RAM VPS, where I needed to compile something - you don't want a 512MB VPS to do a lot of compilation, but in that one instance, I was very glad I could easily just make a swap file and get on with it. The other time was on my laptop with 8 GB of RAM.

Also, even ignoring the times where swap makes possible a task which would otherwise have been impossible, you flat out ignored the content of the article. Did you even read it? If you have a long running task which allocates a lot of memory, then proceeds to only very rarely use that memory (or maybe it only needs that memory when it shuts down, or just forgot to free that memory), swap allows the system to swap out that memory and instead do something useful with it, like caching files or not killing processes. It doesn't matter that the disk is slower than RAM, if the swapped-out memory is rarely or never accessed.

[b4lancesh33t]

Well, they wouldn't have been literally impossible. Anything that can be done with swap can be done by writing the data to disk and then reading it back. That's all swap is doing.

[mort96]

Ok, you are technically correct; I _could_ have changed GCC to cache stuff to disk instead of keeping everything in RAM (which would probably have been a big refactor), but I think we both know that's not really practical.

[Someone]

32GB/s is 128× 256MB/s, not 320×, and 16GB is 1024× 16MB. The latter, I think, is the reason swap has gotten less useful. It seems even modern programmers don’t know what to do with all that RAM (possibly because, at top speed, it takes 8 times as long to fill it all up (about 20 times as long if the data has to come from a hard disk)

[al2o3cr]

    hard disk xfer is 500 MB/s

You need better disks. The one in the laptop I'm typing this on can do 2GB/s, which greatly weakens your comparison.

[joosters]

They won't be able to achieve anything like 2GB/s when handling reads from swap, because they are likely to be lots of small chunks of reads - the pages being swapped in are often 4k and will be very difficult to predict, so bulk I/O will be unlikely. Same goes for writes, with the added proviso that your SSDs will have far worse small file write performance than reads, which is probably the 2GB/s headline figure.

A better statistic to use is how many IOPS the disk can handle.

[tmyklebu]

If I may ask, which disks are you using?

[sigstoat]

the highest end NVMe SSDs can sustain those multi-gigabyte/second reads. https://smile.amazon.com/Samsung-950-PRO-Internal-MZ-V5P512B... for instance.

not sure even they could pull off those speeds with random reads, though.

[deathanatos]

I think when most people say "hard disk", they usually mean rotating discs that use magnetism to store data. That is what I took tmyklebu's question to mean, since I too have never heard of a HDD reaching anywhere near 2 GB/s.

[sigstoat]

> I think when most people say "hard disk", they usually mean rotating discs that use magnetism to store data.

while i would personally avoid referring to an SSD as a "hard disk", i was attempting to interpret the original claim in the most charitable possible fashion, since it was utterly absurd if interpreted strictly.

[tmyklebu]

Either way, I learned something. I can picture an array of 20 disks sustaining 2GB/s, but you aren't going to fit 20 disks into a laptop. I didn't realise a high-end SSD could get there, or even how much better regular SSDs are for throughput. (That cost per TB, though!)