I think that the new behavior at zero (documented anywhere?) is a discontinuity. There should be a separate setting for mlocking code pages.

Swap is useful even if you have plenty of RAM. It's better to swap out a cold file-backed page and use that page for cache instead than to pin that cold page in memory for no reason.

Gah. I meant non-file-backed

That's what ZRAM is for.

It's also what swap is for.

Funny, but Linux is the only unix-like OS I've ever run where using swap means you have a problem. Other OSes have much more intelligent memory management.

For me swap is an error. I would rather a server crash then go into swap and run slow.

If your servers are at 75% CPU and start swapping you are screwed. Time to start adding servers. In this day and age you are wasting a lot of money to be sitting around waiting for swap.

zswap makes swap useful on the server as it results in gradual slowdown when the system has used all the ram. And if the system runs at 75% of CPU, then there is room for such slowdown.

I hadn't heard of zswap [0]:

"Zswap is a lightweight compressed cache for swap pages. It takes pages that are in the process of being swapped out and attempts to compress them into a dynamically allocated RAM-based memory pool. [...] Zswap is a new feature as of v3.11 [...] zswap is a work in progress and should be considered experimental."

The return of RAM Doubler!

The naming is initially confusing if you're already familiar with ZFS, especially:

"Zswap makes use of zpool for the managing the compressed memory pool"

[0] https://www.kernel.org/doc/Documentation/vm/zswap.txt

It's actually quite useful on many consumer devices, especially those with multiple cores. Most of the time I'm happy I can trade a few CPU cycles for better I/O performance.

yes, we run ZRAM of every single server we have, its fantastic and we don't have swap anywhere. It's worth noting though that vm.swappiness is set to 0 then ZRAM wont be used, it must be set to 1 or higher unless you're using a really old kernel (pre 3.5).

I have found that zswap behaves much better than zram when the size of the used ram approaches 150% of RAM. In theory zram compresses better as zswap has very simple mapping for the location of its cache of compressed pages leading to space underutilization. But, as it has real backing store, it can evict unused pages allowing bigger chunk of uncompressed memory for running applications.

zram[0] is not the same thing as zswap[1].

0. https://en.wikipedia.org/wiki/Zram

1. https://en.wikipedia.org/wiki/Zswap

It's not the case on Linux either.

Linux intelligently swaps out ununsed pages even if there's enough physical RAM (that is more useful as page cache).

I have FreeBSD systems that use gigs of swap with gigs of memory free. If you have a Linux system with that much swap usage it's usually about to crash (as it struggling under memory pressure)

People should stop monitoring swap usage and start monitoring the amount of page in / page out IO.

Not true. I have plenty of Linux systems that use gigabytes of swap with 100+GB of free RAM.

Monitoring swap usage doesn't make sense on either FreeBSD or Linux.

heh, try using Windows when it goes into swap, Windows both desktop and server additions have the worst memory management I've ever seen and having no ZRAM and a pig of a filesystem like NTFS really doesn't help either.

Going into swap in Linux isn't a problem, it's a symtom of a misconfigured / provisioned server or an unhanled application memory leak, other than that the other only things that should cause it is incorrectly configured use of shared / reserved memory.

Disk based swap should pretty much always be disabled these days and ZRAM used to incresed efficiency.

> having no ZRAM

Windows 10 has had memory compression [1] for quite a while now. On the PC I am on at the moment with 100+ Chrome tabs open, I have 1.3GB compressed out of a total of 16GB.

[1] http://www.thewindowsclub.com/memory-compression-in-windows-...

Works very well on Windows Server 2012 and saves massive amounts of money with some workloads.

Incidentally, at least on Windows, you can save a ton of harddrive space by changing your swap settings - the default is crazy high, especially if you have lots of RAM.

My laptop has 8 gigabytes of ram. I can fit all of my personal files in that at obce, I don't see why that's not enough for everything.

Space used on disk is less than when the data is in RAM. It's not a binary copy loaded. It's binary data loaded then inflated into app-object memory. So much overhead

I’ve run with 4 GB of memory and no swap for a long time. It’s not hard.

Swap makes a lot of sense for a consumer device, where I'm opening a big spreadsheet, then putting that in background to edit this video.

It makes less sense for server workloads, where you usually don't have huge chunks of inactive memory.

I always run with no swap in AWS, especially with the newer EBS-only families.

EBS is a problem because in reality you would be swapping to a network volume. But on a standard VPS server, a bit of swap can really save you some problems. Swap was invented at a time when *NIX was strictly used in a multi-user environment, not far removed from today's webservers but very different from today's consumer devices. It still serves a purpose in that role.

> [...] a bit of swap can really save you some problems.

And cause a bunch more. Have you ever had to debug a race that is only triggered when a process hits swap. Not fun at all.

Yes I did, and the swappy machine started responding just a tad too slowly to other nodes' pings, engaging into a loop of join/parting the cluster, causing replication to kick in all the time and a whole "highly available" critical cluster of 9 nodes was unable to handle traffic (too busy replicating) causing millions in losses. So yeah, don't use swap in servers.

Ironically, if the node had crashed for OoM, the cluster would have survived just fine.

>"fix of previously broken behaviour" as in 0 not being able to disable swap entirely

But you can disable swap entirely by not having a swap partition/file, so I don't think that's a huge issue.

It was indeed a massive, not well discussed change and the kernel maintainers should have vocalised it better (not that I think the Ubuntu maintainers wouldn't understand it properly anyway TBQH) but yes, the behaviour was previously logically incorrect and had to be fixed at some point.