[GTALUG] Swappiness

[D. Hugh Redelmeier]

| From: Russell Reiter via talk <talk at gtalug.org>

| Desktop freezing can be an issue if you don't get the ratios in line with
| the hw.

Really?  swappiness values (except for 0) should only affect
performance.  Not something binary like freezing.  Of course really
really really bad performance can appear to be freezing.

| I've been considering this a bit for my own desktop. In order to mitigate
| possible write amplification issues on my SSD running RH F27, at this time
| I have 8gib ram with a 4gib swap.

swappiness should not have a direct effect on write amplification.
The obvious way of affecting write amplification is by
overprovisioning (as we've discussed before).

swappiness could and would change the number of writes.  Except in
pathological cases I would not expect swap to challenge the lifetime
of an SSD.

|  Apparently, on more modern systems, if
| you have greater than 2gib ram you are in a better position to play around
| with the checks and balances.

There is no magic number independent of workload.

I have an inexpensive RHEL 7 OpenVZ instance in the cloud with 256G of
"RAM" that seems to work fine.  No desktop or X, of course.

2G seems to have become too low for me to pleasantly web browse on
Fedora 28.  It still works but can get sluggish with web pages that I
visit (a few tabs of Ars Technica, for instance).

swappiness is not a check, only a balance (except for 0).

For most ordinary workloads, swappiness should only matter when memory
gets tight.  2G would be a good example.

swapping behariour generally follows a hockey-stick curve.  Anything
you can do to stay left of where it takes off is worthwile.  Anything
moving you further left from that isn't very important.

(Write amplification also involves a (different) hockey stick curve.)

Another interesting thing to play with might be zswap.  I've never
tried it but some claim it is quite effective.  Essentially, with
zswap: swap has a compressed cache in memory; actual writes may be
avoided.  To me this feels like a way of bumping things towards the
left on the hockey stick curve.  So it should matter on some systems
and workloads and not on some others.

<https://en.wikipedia.org/wiki/Zswap>

| On my M.2 Nvram in the same system running RH F28 where I let the system
| installer choose for me, I am experiencing certain display widget redrawing
| issues in that the widget is blacked out until the mouse hovers over it.

That should have nothing to do with swappiness.  Unless there is some
pretty odd bug.

| However at this time and considering all the microcode updates for my MB in
| the last eight months, I'm unsure whether this is connected to the display
| drivers or the swap parameters.

One never knows what it is connected to until one tracks it down.  But
swappiness is that last place I'd look.  Microcode updates might be
the second last place.

The first place I'd look is the video driver.  Those are very
complicated and too often buggy.  Consider switching between X and
Wayland to see if the problem follow you.

Of course the zeroth step would be to discover how to create the glitch
reliably.

| I haven't had much time to hack around lately, but as I stabilize this
| build, I definitely don't use hibernate and suspend as they draw heavily on
| swap.

As I understand it (imperfectly) hibernate uses swap (and common sense
says you need enough swap to hold all dirty pages) and suspend uses no
more than the system did before suspension.  So only hibernate draws
heavily on swap.

Generally speaking, hibernate isn't done often enough to challenge SSD
lifetimes.

You really need to think quantitatively to understand what matters in
performance.  That includes SSD lifetime issues.  Hockey stick curves
drive one into non-linear systems, something a little harder to deal
with.  "The Tipping Point"