@drewdevault I don’t use swap! Really, with modern systems, what’s the point? If I run out of 16 GB memory running 4 applications, I have other problems.

Browsers are pigs, though. Never thought a styled text display programme would be the biggest drain on performance. Then again, the browser is the computer.

@drewdevault @ttmevans
True, but @ttmevans' point is still valid, if the RAM you have is enough to support what you do, swap is superfluous

I don’t think that’s true, the swap on my server is used despite the memory usage never going even close to full usage.

The most known/discussed feature of swap is to act as some extra (barely usable) memory when the RAM is saturated, but it is not the only one.

(talking here about a server or some other system running for long lengths of time, it might not be that useful for a computer that is turned off every night)

CC: @drewdevault@fosstodon.org @ttmevans@mstdn.social

@drewdevault @levitte @ttmevans obligatory mention of the excellent https://chrisdown.name/2018/01/02/in-defence-of-swap.html article.

The purpose of swap is to balance memory pressure between the page cache and anonymous pages, so when memory pressure occurs the kernel has the ability to evict not-recently-used anon memory instead of just the page cache.

The page cache intentionally keeps a hold of file pages until reclaim so we can avoid disk I/O as much as possible, therefore naturally RAM usage grows over time.

Without swap the kernel has to ALWAYS evict page cache pages meaning that you might end up having to do a bunch of disk I/O that you might not otherwise have to have done.

TL;DR: Swap lets the kernel use memory for what is most in-demand, whether that is anonymous memory or cached file memory. Turning it off means that stale anonymous memory is ALWAYS preferred over cached file memory even if that doesn't make sense.

EDIT: Didn't realise Chris was on fedi - @cdown - incredible article, love it!

@ljs That's interesting. I always assumed it was only used as "extra memory".

@thomy2000 yeah it's a super common misconception and I don't think it's been communicated very well.

The incredible @cdown explains it wonderfully in his essay on the subject.

@ljs @drewdevault @levitte @ttmevans You're very kind, and thanks for the poke :-) I have been meaning to update it with more graphs/data, better sidenotes, and in general bring it up to date with more recent developments. Hopefully I will have time to do that soon.

@cdown @drewdevault @levitte @ttmevans I am a huge fan of your work! Really loved the talk you gave about MM at scale [0], saw that years ago and was inspirational!

As for recent developments I saw the swappiness -> memory.reclaim for cgroupsv2 fly past not long ago [1] which looked interesting, though it seems cgroups v1 had this and Tejun wasn't a fan of keeping it there.

Cgroups definitely give a ton of fine-grained control in general for throttling things. My book explicitly doesn't cover cgroups (due to time) which is a pity as it's a really handy tool in the toolbox, not only for those using containers...

[0]: https://media.ccc.de/v/arch-conf-online-2020-6390-linux-memory-management-at-scale
[1]: https://lore.kernel.org/all/20240103164841.2800183-1-schatzberg.dan@gmail.com/

@ljs @drewdevault @levitte @ttmevans Aside from technical concerns, the swappiness business is hairy at least in part because it races with sysctl setup. For example, on cgroup v1, the value would almost always not be updated from the default of 60 because cgroups were setup before sysctls were read and updated from sysctl.conf. After my talk at Kernel Recipes last year I [...]

@ljs @drewdevault @levitte @ttmevans [...] went on an unscheduled rant about sysctls and that they should be replaced with more granular interfaces during Q&A (https://www.youtube.com/watch?v=crZwA7JbxGw&t=2344s) which, judging by the reception in the room, was generally agreed with, so hopefully I'll also have some time to think about how we might best go about that in the coming couple of years. My vision is [...]

@ljs @drewdevault @levitte @ttmevans [...] that we have these tunables in something akin to namespaces, but both from a technical perspective (most tunables are just direct writes/reads to some object in the kernel, look at int arrays for example) and from an API perspective (which sysctls are reasonable to tune in a more granular fashion), this is probably a multi-year endeavour.

@cdown @drewdevault @levitte @ttmevans ugh yeah, that racing with sysctls is grim.

I've felt like tunables have _often_ (but not awlays) been a way for kernel developers to simply offload a decision that really should be heuristic onto users who may have little to no understanding of what the tunable actually impacts.

Swappiness isn't like that, as it's pretty well understood and _IS_ something that a user should control, but it's very very coarse, and deciding how best to tune that well...

Some way of more generally improving upon the [yes precisely as you say something that maps to a kernel global] with namespacing or some more fine-grained control would be excellent.

I wonder to what degree that overlaps with the whole concept of cgroups of a hierarchy of specific memory/cpuset/etc. settings and how that'd interface though.

But maybe a conversation to have on-list or something :>)

What do you think about the -next feature I linked that allows swappable to specified as part of cgroupv2 memory.reclaim? I assume it overrides sysctl across the board, not looked at the patch series in detail.

The general ability to alter how swap behaviour performs at cgroup level seems useful generally.

I wonder if we could see some reclaim stuff happen similar to MGLRU that gives more control to the user over how the decision is specifically made overall too.

For the longest time Kubernetes kubelet did not support swap on worker nodes. Many still held it as true even though swap management feature has gone beta since version 1.28 (Aug 2023)
https://kubernetes.io/blog/2023/08/24/swap-linux-beta/