[conspire] Vee don't need no steenkin' swap! ;-)

[Rick Moen]

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

> >Good news:  The Red Hat people say there should be no problem.
> >https://www.redhat.com/en/blog/do-we-really-need-swap-modern-systems

[About Red Hat technical page stating there's no problem with a swap-less
system:]

> Oh, it's been said/implied by lots more than the Red Hat folks, and for
> quite a long time now.  

Well, let me give the background on that:

In a recent discussion on the Dng list, there was discussion of
partitioning strategies to take best advantage of SSD storage, including
a lot of things like choice of FS and mount options.  I mentioned that
swap can and probably will have pernicious effects on an all-SSD system,
causing premature exhaustion of the devices' read-write life cycle
without compelling compensating benefit in a typical use-case.
Therefore, I said, I am looking into swapless operation for such
situations.  

This comment immediately drew out the predictable worry-monger, wagging
his fingers and saying (paraphrased) 'Oh, woe betide the reckless admin
who tries that, because blah-blah instability blah-blah.'

So, I made a note to check and see if anything beyond anecdata from a
net.random supported his worry-mongering -- and the answer turned out to
be 'no'.  Given ample RAM and a reasonably well-known RAM-usage pattern, 
there are no _generic_ system-stability concerns, i.e., there is no code
in modern kernels that freaks out and misbehaves _just_ because there is
no swap available.

I strongly suspected that the net.random in question was pushing, um,
slightly used cow food because of his rejoinder to my next comment in
the thread:  I thanked him for reminding me about the _possibility_ that
constructing a swapless system could lead to unsuspected stability
problem in normal operation.  I went on to say that it would at minimum
be prudent to test a swapless prototype before putting them into
production -- but that, fortunately, any problems observed could be
alleviated by adding a swap _file_ rather than a swap partition.

I commented that swap files used to be routine in early Linux days but
fell out of use because swap partitions had better performance, but that
the performance gap had actually been eradicated during the 2.6 kernel
development cycle, and most admins just hadn't noticed.

The guy wrote back to say that, no, a swap file would be bad because it
_had_ to be significantly slower on account of filesystem overhead.
This told me he really didn't know fsck-all about the topic, but just
enjoyed putting his oar in, i.e., just another bored net.random
dispensing questionable advice.

In fact, the 2.6 (and later) kernel doesn't read swap partitions via the
filesystem, but rather maps what disk blocks it's stored on and accesses
them directly -- the exact reason why the performance gap got
eradicated.

http://lkml.iu.edu/hypermail/linux/kernel/0507.0/1690.html

On a hard disk, you would still be concerned about -fragmentation- over
time, which if it accumulates would create a performance gap compared to
a swap partition.  But on an SSD, with no disc seeking, that concern
goes away.



> "It depends" - at least somewhat.....

What the _gehenna_ do you mean by that, Michael?

If you mean 'a swapless system that runs out of RAM hits the OOM killer
sooner' or 'Linux likes to move memory pages that are hardly ever used
to swap' or 'better have adequate swap if you want the host to
hiberate' or 'better tweak vm.swappiness to something less insane than
60', then -- duh!

On an SSD-only system, moving unused memory pages to swap is expensive
in SSD wear.  Which is my _point_ -- that SSDs suggest some rethinking
of old habits and routines, and one of them is reexamination of
attitudes about swap.

This includes (also) ensuring that any filesystem on SSD is aligned on
an erase block boundary, by the way:
http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/