As long as you have only spinning rust for swap I disable it. After reading that article some time ago I tried to add a little swap to my shared general purpose machines (running quite a mixed workload that sometimes tends to explode e.g. matrix synapse is famous for that) and the box still grinded into an unresponsive state even with just 4GB swap. Maybe I did something wrong - But I'd rather tolerate an OOM kill (mostly contained by cgroups/container/lxd) and a few seconds (or minutes) of unresponsiveness instead of a complete lockup that results in a hard reset. Not sure if it's better on SSD. I've enabled zswap for 1/8 of memory on the Desktop and this seems to improve things but as long as you have spinning rust or other slow storage my experience is that the machine will die a slow death as long as swap is active.

There is some interesting stuff in newer kernels - like multigenerational mru [1] and that le9 patchset [2]

Am I missing something? If you have full control over the memory usage this might be useful for the mentioned usecase but for a general purpose machine this doesn't work?

1: https://patchwork.kernel.org/project/linux-mm/cover/20210818...

2: https://github.com/hakavlad/le9-patch

Interesting. I used to have considerable swap as the last line of defence against certain memory hog cases, back with not-very-fast spinning rust (Thinkpad R61i). I rarely had heavy thrashing, and worst case I had the choice of killing Firefox (4.0 back then!) or making fresh cup of tea - but usually it meant that things would spill over then get back into good condition.

Funnily enough, I mostly suffer from thrashing today, on Mac, especially with chrome. And it's mostly with compressed memory, though overzealous nature of swapping in macos doesn't help.

>On SSDs, swapping out anonymous pages and reclaiming file pages are essentially equivalent in terms of performance/latency... >we simply transfer the disk I/O of swapping to dropping hot page caches and dropping code segments we need soon

That's a key argument, but it ignores that swap changes a read I/O to a write I/O - on HDD write is much slower (this is acknowledged in the article), and SSD have a write limit (this is not ack'd).

I know all SSD manufacturers these days say their limit is high, but I'm still a bit leery.

There is also issue that SSD write is much slower than even HDD write once internal buffers are saturated, and has unpleasant consequences.

When my system got thrashing (droping hot pages) due to memory pressure in a limited cgroup, i see continuous 400MB/s disk read traffic (as pages are read and then dropped), but the rest of system (outside the cgroup) is usable. But when i do some big file copying, the SSD sometimes causes multi-second system freeze due to locked SSD I/O.

Also, the write limits are pretty tight. Recently, i replaced my SSD after just 6 years of light use, because it reported average sector overwrite rate to be ~3300 of 3000 nominal lifetime. And current TLD and QLD SSDs have these limits even smaller.

Aren't the write limits on ssd going to be lower again with mlc?

I think we're at tlc and qlc for common SSD drives now? And soon enough plc?

Manufacturers always say the write limits are very high despite using less durable tech, and I am not sure I believe them.

These days with consumer desktops coming with 96GB of ram, I would say that instead of risking your OS doing something...suboptimal with swap, just get more ram.

Call it an early Christmas/Birthday gift, and be done with it. Life is too short to wait for Firefox to page back into main memory