[edwintorok]

Except thats not what causes problems in practice. You get problems with swap when your working set size exceeds your RAM. You'll always be hitting the disk as long as the offending application keeps using too much memory, and it slows down the entire system not just that one application. When you try to SSH in/log in that requires reading files from disk (or swapping things back in) which can take quite a while due the backlog caused by swapping.

If you ran out of memory and malloc returned NULL that would be better, however a lot of applications rely on overcommit so there is no good answer:

* you can run with RAM + as much swap to make all applications happy and overcommit off, and accept the long delays caused by swapping

* run with just RAM, overcommit on and no swap, and accept that your applications may be killed by the OOM killer anytime

[scott_s]

As has been stated several times in this thread, the "swappiness" factor is not about over-committing RAM. It's about giving the kernel the freedom to say, "Hey, these pages in RAM have not been used in a long, long time. I'll swap them to disk so I can use that RAM for things that will speed things up more, like disk caching."

This is independent of applications whose working set size exceed that of physical memory.

[edwintorok]

Yeah my reply was to the "disable swap" part of the discussion, not the swappiness one.

[scott_s]

Disabling swap means setting swappiness to 0; I'm not sure how you can talk about "disabling swap" without talking about swappiness.

[edwintorok]

Because that depends on the kernel version, I took the more reliable approach of using 'swapoff -a' (or in fact not defining any swap in my /etc/fstab). https://news.ycombinator.com/item?id=7940387 https://news.ycombinator.com/item?id=7940136

[scott_s]

Which then means that you're not allowing the kernel to make such decisions as what I described. (Rarely used pages paged out to allow for more disk cache.)