With NUMA swap etc. also becomes a bit more complicated (see also https://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the... )
I think the main question here is to use a swap partition or a swap file.
The main problem of swap partitions is how inflexible they are, but lvm/btrfs/zfs make that less of an issue.
On Solaris a crashdump was written to swap when the system panicked. Not sure what Linux/BSD crashdump systems use nowadays.
Yea, that's true.
Just recreate the swap with the desired size. Extra easy with LVM.
I've done this on both FreeBSD and Linux, never had a problem. However, IIRC there might have been some issues in the past on Linux.
Every year or so a program (usually firefox) would spring a leak and lock up the machine for a minute or two then the OOM killer would kill it. This would have happened with or without swap; I think it's faster without?
So haven't bothered with partitions for a while. But a couple of years ago, the dists starting adding swap files by default. Ok, I thought, I won't fight it.
I do keep it reasonable, one or two gig. No problems so far. NVME is pretty darn fast, though htop says I don't really use it.
Get enough RAM for your use case, double if on one of those soldered Macs. This served me well, we had a 2013 MBP in great working condition (because I disregarded the salesbot advice and got 16gb) still works great but the recipient wanted a new M2 this year.
Personaly went with the Framework so not worried.
I thought write text files may need swap partition more than others?
My text files are typically under 100k and a good editor will pull larger ones in as needed. 0% of them are larger than RAM, ~16 GB.
Doing so for years. No big issues other than the occasional website (scripts, use of top-heavy web frameworks or whatever) causing runaway RAM usage. Local apps (including some older games, electronics design stuff) run fine.
Most sensible argument for using swap I've seen is a memory leak on server hardware, where having swap keeps the server at least running, buying the admin time to figure out what's going on.
On my PC, if an app leaks memory, I want to see free RAM going down to the point where something will crash - asap (no swap). Giving me a good sense which app (or website) was the culprit.
Not (with swap), the whole system getting slower & slower, but with a delayed fuse & much fuzzier clues about which app caused the problem.
Pick workflow + OS + apps such that working set fits RAM in the machine, and be happy. If needed, change OS / apps / workflow, or add more RAM.
Not: take app that needs 16 GB to run acceptable, run it on 4 GB machine, and use swap to somehow make it work while the user experience makes you cry.
So, imho: no need for swap on modern machines. Unless (maybe!) it concerns an internet facing server & uptime is critical.
I use HHHL PCI SSD to host my swapfile to withstand with rapid read-write activities
Depending on budget (and how expensive you consider your / development time), just choose between:
a) Use smaller ML models / tweak configuration such that it actually fits into 196 GB. That's already a ffing humongous amount of RAM! Or
b) Bite the bullet, and add RAM to fit the ML model(s) you're using.
Your workflow sounds like running Win95x on a 1 MB machine. Painful! (if it works at all). Just add the RAM, or slap DOS + Win 3.x back onto it.
I thought most OSs would just be using specialised sleep state files given that the hibernation image would need to be a serialised dump of all allocated memory whether resident on physical or paged out to the swap space. By extension, with swap disabled hibernation could still happen as long as there's enough physical memory free to handle writing to the sleep image on disk.
Swap space can be used for [...] suspend-to-disk support. https://wiki.archlinux.org/title/Swap#Activation_by_systemd
In order to use hibernation, you must create a swap partition or file [...]. https://wiki.archlinux.org/title/Power_management/Suspend_an...
Maybe I can learn something here. From my understanding, the RAM image moves completely to the swap space, since the RAM memory is shut down (cleared). I thought, that's why it's calles 'suspend to disk'. During hibernation most components are in a state of being almost shut down. And that would be why you need a disk that can hold data non-volatile (eg not the RAM memory). Edit: From your comment it reads like the swap space is only for assisting the process, while from my understanding that's the place where the whole RAM image resides during sleep.
> a swap partition for the purposes of hibernation, while also disabling swapping of memory while your machine is in-use.
I thought the exact same. Avoid tear of the SSD and security implications, while having the option of hibernation (including the security implications) in case of need.
I think your understanding is broadly correct. My point was centred on the nuance that the primary purpose of swap space is for the OS to move less frequently used parts of virtual memory to disk to allow more recently/frequently used virtual memory to occupy the physical RAM.
So theoretically, if you wanted to implement hibernation on top of such a system, you wouldn't need the OS to have swapping enabled. (Although from your examples, practically, in some cases at least you do)
Without swap space, the OS would still use virtual memory addressing and allocation, but it would only be translatable to physical addresses in RAM, and exhaustion of RAM would lead to the OS out of memory killer to start killing processes to free RAM up.
But you could still write a hibernation program to take everything in memory and write it to disk and restore it later even if you're not using the OS swap capability to provide programs with the illusion of more memory to use than RAM allows.
Now in theory the OS could not swap and still hibernate. Windows might do that if you disable the swap files. Linux might do that on minimum swappiness but you could also swapon what you need before hibernation and swapoff after boot/wake.
Could you please be more specific?
Personally, I find utility in having something approaching max(512mb, 2xRAM) swap available. If you've got an older system, 2xRAM is a good rule of thumb, but not for larger ram. IMHO, swap usage falls into two categories: slow leak and fast leak. In a slow leak, size doesn't really matter, just that it's being used, you can set your alert at 10% (or 75% or wherever) and you'll hit it eventually regardless of underlying size, in the mean time everything works fine, no big deal or urgency. In a fast leak, the system tends to get really slow really quick, until you hit the swap limit and then things usually get broken and fast; maybe if you get in early you can kill things before it spirals, but chances are you won't, and you'll just need to wait until you hit the max and then pick up the pieces; having a small swap means the time of max swapping is pretty limited.
TLDR: a small swap partition gives you a clear indication of a slow leak, but doesn't prolong agony during a fast leak.
Also note, measuring used memory is hard, but measuring used swap is easy. If your system typically has 0% swap used (which it should!), and starts swapping, you know something changed to use more memory (or the kernel swap algorithms changed)
On my 64 GiB server, I have 4GiB, same reason.
Kernel has actually swapped out some stuff, probably ubuntu bloat stuff that's never used anyway.