[old-gregg]

I don't recommend this anymore. With a typical developer machine containing 16GB of RAM, and especially on Linux, you will that all of your daily-touched files are in FS cache after a few minutes of work. Even with default kernel settings Linux is pretty good with eating up all of your unused RAM for speeding up disk access.

Here's my anecdote based on 16GB workstation with NVMe SSD (Samsung 960 Pro):

Watching my project compile I occasionally open iotop in another terminal and don't see anything above occasional write flushes. To confirm, I did create a tmpfs volume and did not observe any improvement. `free` reported my buffers to be at ~4.7GB, which is basically all of my /bin, /usr and all of Golang sources+libs.

[FeepingCreature]

One memory leak and your cache is gone.

[edit] Not sure if ramdisks are pinned though.

[ars]

> Not sure if ramdisks are pinned though.

Ramdisks will go to swap. A memory leak will force the entire ramdisk into swap, and reading it back into memory afterward is 10 to 100 times slower than reading normal files off of a disk.

[majewsky]

> Ramdisks will go to swap.

Assuming that you have swap. I don't; I want my SSD to stay alive.

[ars]

If you have a memory leak, and a ramdisk, and no swap then the OOM killer will trigger.

Hopefully it will target the program with the memory leak, but this is not guaranteed.

Swap is useful because you can shift unused memory onto disk. There are many programs that allocate (and write) a lot of memory that they never afterward use.

By having swap you make more room for cache in memory.

SSD doesn't matter here - this is not swap thrashing, but rather occasional writes.

[mavhc]

Does anyone have actual data on swap on SSDs in 2017?