[wahB4vai]

I'm a big fan of determinism and service uniformity. Having that rarely used and response time critical function/data/whatever swapped out increases service time variation at best and complicates all worst case response time calculations at least.

I understand from the land of JIT compilers, garbage collectors, and oversubscribed everything that this is not much of a substantial concern as these features are already traded away.

The swap may be the best case in a bad situation. I would argue along the lines of don't be in a bad situation...

I'm looking at you 8 of 16 GB used on cold boot Mac laptops... Looking at you with indignation and rancor Chrome.

[caf]

One of the article's points is that running without swap doesn't necessarily alleviate that. The rarely-used code pages of your rarely-used but response time critical daemon can just as easily be dropped from the page cache and have to be refaulted in from disk, and in fact that's more likely if there isn't swap available to stow the dirty anonymous pages from the cron daemon that wakes up once a day or whatever.

The solution for your rarely-used but response time critical daemon is for it to mlock() its critical data and code pages into memory, which works regardless of whether or not you have swap available. (Or, alternatively, use one of the cgroup controllers that the article alludes to, to give the critical daemon and related processes memory unaffected by memory pressure elsewhere in the system).

[AstralStorm]

No they cannot. Code that is loaded into memory stays in memory when three is no swap. (Mlock is to prevent swap out or compression - major faults.) The exception would be lazy library loading. BIND_NOW is your friend in this case.

Essentially having no swap is similar to having everything mlocked - no major faults can happen except with mmapped files which will just use direct disk IO.

If you mean disk caches, when have you seen a multigigabyte executable?

[caf]

Code that is loaded into memory stays in memory when three is no swap.

That is not true. In the normal case (absent debugging, JIT, self-modifying code etc), pages of executable code are clean, shared mappings so they do not interact with swap at all.

As clean, shared mappings they are eligible to be dropped from the page cache in the same way as other clean file mapped pages.

(Your executable code pages essentially are mmapped files. )