This is not entirely correct. If you care about latency, then it doesn't matter on which major fault your application gets paused. Disabling swap protects you from data pages being evicted, but code pages can still be paged out.
If you care about latency, mlock() your memory, do not disable swap. Swap is good and gives the kernel an equal opportunity to evict data and code pages.
For GC enabled languages swap is universally bad. Some gc-pauses are indistinguishable from a system crash. It's a side effect on not having tightly specified memory limits.
I'd rather have applications be oom_killed than having them swap out, the former is rather obvious and demands action.
If you want you application to stay in memory, then make it explicitly with mlock()/mlockall().
Disabling swap will just moves pressere elsewhere: to code pages. And evicted code page is no better: full stall while kernel loads that page from disk.
I think discussing it in a vacuum is pointless, it should depend on how much memory you have. You can have a swap on, but with a low `vm.swappiness` number.
Surely as long as it is all in memory these pauses are not going to be that significant, details like that should be left for the language devs to optimize.
You can tell an average Golang user to use mutexes, you shouldn't be telling them to lock memory manually.
jacobgold · · focus · HN ↗
"Stop doing that"
If you care about latency, disable swap. System wide or for the specific the cgroup.
delamon · · focus · HN ↗
If you care about latency, mlock() your memory, do not disable swap. Swap is good and gives the kernel an equal opportunity to evict data and code pages.
xxs · · focus · HN ↗
I'd rather have applications be oom_killed than having them swap out, the former is rather obvious and demands action.
delamon · · focus · HN ↗
Disabling swap will just moves pressere elsewhere: to code pages. And evicted code page is no better: full stall while kernel loads that page from disk.
xaduha · · focus · HN ↗
blueflow · · focus · HN ↗
xaduha · · focus · HN ↗
You can tell an average Golang user to use mutexes, you shouldn't be telling them to lock memory manually.