Is "swap" still necessary/relevant?

T

taiwan740

Just spinning up a new instance of FreeBSD 14 on a VM. The Guided UFS disk set-up using the entire disk has reserved 3.8GB out of a 120GB disk for swap.

Usually I go in and manually delete this. I realise it's a luxury but most of my kit has 16GB of RAM, and VMs are given 8GB of RAM (I run one at a time, as just a desktop user)

Is swap still necessary in this day and age? I can understand having a memory overflow is helpful but perhaps these days it's a bit redundant, unless there is some other use for swap that I'm not aware of, in which case I'd appreciate the learnings.

Thanks
 
Not providing swap space forces the OS to drop readonly mapped pages at an increased rate (that means even if they are potentially useful) because it cannot swap out read-write pages that are indeed useless. For example, that can leads to excessive dropping of pages containing code from compiled languages.

16 GB is not a lot, especially if you gave 8 GB to a VM.
 
Last edited:
Weirdly enough, the only platform where I have needed swap enabled to function is OpenBSD on a Raspberry Pi. Without one (even a tiny 1MB swap file), random processes are "Killed". It seems to be a known issue, potentially a bug in the memory manager.

Typically, on a desktop, I would have a 2GB swap. Otherwise (i.e sdcard), then I skip it.
 
If I recall correctly, swap is used for kernel crash dump by default.
(Sorry, still cannot find evidences for current default.)
If this is correct and the default is still uncompressed full core, you must have at least real memory size plus alfa for swap. Without it, savecore(8) cannot salvage saved core to /var/crash/ (default).

An old but interesting document: gwydir-The_History_and_Future_of_Crash_Dumps_in_Freebsd.pdf

And if hybernate-to-swap feature is implement in the future, more space could be rquired for safety. Unfortunately, I don't know whether someone is working on it or not.
 
T-Aoki said:
And if hybernate-to-swap feature is implement in the future, more space could be rquired for safety. Unfortunately, I don't know whether someone is working on it or not.
Click to expand...

There are rumours of hibernate to disk - ACPI S4 state - being worked on (at last), but where is talk of hibernate to swap?

S4 requires saving ALL of CPU and memory state - RAM, used swap and graphics memory - to disk. I guess any unused swapspace on disk could be part of the allocated space, but that seems prone to difficulty and delay compared with a preallocated partition or file as more commonly used.

Just musing; it's years since I was anywhere near ACPI code.
 
smithi said:
There are rumours of hibernate to disk - ACPI S4 state - being worked on (at last), but where is talk of hibernate to swap?

S4 requires saving ALL of CPU and memory state - RAM, used swap and graphics memory - to disk. I guess any unused swapspace on disk could be part of the allocated space, but that seems prone to difficulty and delay compared with a preallocated partition or file as more commonly used.

Just musing; it's years since I was anywhere near ACPI code.
Click to expand...
In APM, BIOS had the resopnsibility for sleep/hibernate and where to hibernate (save to disk) purely depended on BIOS implementation.
Some forced basic partition with specific type, some allowed extended partition, and some saves to first FAT16-formatted partition with specific file name.

In ACPI, if I recall correctly, the responsibility is passed to OS'es working on it.

Back to hibernate-to-swap, I found Linux-related document. It states "About Arch Linux. States that Saves the machine's state into swap space and completely powers off the machine.". See section 4 for details.

For FreeBSD-specific, I couldn't find directly mentioned about it, but found some related notes.

  1. Suspend/Resume on FreeBSD wiki.
  2. Post to freebsd-hackers ML linked from Suspend to disk (hibernation) entry on FreeBSD Foundation-supported projects: call for ideas, November 2021.
Both of them didn't mentioned abouto "to swap", but if we, FreeBSD community follow the ArchLinux case, possibly use swap for this.
 
cracauer@ said:
I am not aware of any work toward an equivalent to Linux' kernel-driven suspend-to-disk. It would be a huge job.
Click to expand...
It would be. But using swap, maybe codes for crash dump (to swap) and savecore(8) would partially help. The most difficult part would be resume process. Unfortunately I don't know how ACPI kicks OS'es for resuming from hibernation.

By the way, the first time I saw the word "hibernation" was on APM generation ThinkPads (was 535, which is a Japan-only one) and it was so-called "hybrid mode", which saves contexts to disk and enter so-called "suspend to RAM", silently power off when low-battery condition, and on next power cycle, check for saved contexts, if it exists, do not go to normal boot process and start resuming.
So recent usage of the word "hibernation" sounds very, very strange to me.
 
cracauer@ said:
I am not aware of any work toward an equivalent to Linux' kernel-driven suspend-to-disk. It would be a huge job.
Click to expand...

Indeed, as getting S3 suspend to RAM was back then, early 2000s. I got involved c. 2005 when I bought a used IBM T23 on the strength of it being the platform Nate Lawson used to make S3 really work on at least a range of laptops, with Xorg.

Before and after then I ran a solar powered bush server on a Compaq 1500c laptop that had working APM suspend and resume, for ~15 years.

Noone's made an APM system for at least 15 years, AFAIK.

T-Aoki said:
In APM, BIOS had the resopnsibility for sleep/hibernate and where to hibernate (save to disk) purely depended on BIOS implementation.
Click to expand...

Yes. It also could run defined events at different states of [dis]charge; mine played little speaker tunes as alerts :)

T-Aoki said:
Some forced basic partition with specific type, some allowed extended partition, and some saves to first FAT16-formatted partition with specific file name.
Click to expand...

The Compaq could do STD but I never needed it on permanent solar + house battery power, but occasionally used STR for maintenance.

T-Aoki said:
In ACPI, if I recall correctly, the responsibility is passed to OS'es working on it.
Click to expand...

Well yes, and the quality of FreeBSD's implementation of ACPI, not least from close collaboration with Intel, has been of very high standard. It's allied to that work that I think working S4 might come, not chasing Linux.

T-Aoki said:
Back to hibernate-to-swap, I found Linux-related document. It states "About Arch Linux. States that Saves the machine's state into swap space and completely powers off the machine.". See section 4 for details.
Click to expand...

There's also a pointer there to some good basic definitions:

https://docs.kernel.org/admin-guide/pm/sleep-states.html

at least upto section "Basic sysfs Interfaces for System Suspend and Hibernation" which is more Linux-specific. Written by an Intel guy. Note there's no mention of using swap space, that seems more an Arch? Linux thing.

Arch doc also veers off into systemd, which we don't want to go anywhere near, IMO.

T-Aoki said:
For FreeBSD-specific, I couldn't find directly mentioned about it, but found some related notes.
  1. Suspend/Resume on FreeBSD wiki.
  2. Post to freebsd-hackers ML linked from Suspend to disk (hibernation) entry on FreeBSD Foundation-supported projects: call for ideas, November 2021.
Click to expand...

Yeah, hard to know if there's enough demand. Even with aging batteries my T430 and X200 run for many days in S3 state, so my own interest is just academic. I guess with 8 times the RAM it would help.

T-Aoki said:
Both of them didn't mentioned abouto "to swap", but if we, FreeBSD community follow the ArchLinux case, possibly use swap for this.
Click to expand...

I really think swap's a dead end for FreeBSD S4 STD, which should not depend on hugely reconfiguring swap methods and requirements; I think that would complicate the job enormously and needlessly.

Otherwise it's basically an extension of the S3 STR process, with added saving of memory state(s) to disk, and reworking boot code to offer resume if there's an image to restart from - or more than one, like (re)boot environments?

I'm not trivialising the job, but let's not make it much harder.
 
What's worth noting is that even S3 (supend to RAM) never worked for me, at least fails to resume after switching to ACPI. On APM era, it almost never failed to resume, even from hibernation. So I feel the way extremely hard, even for S3. Of course, I know S3 works fine for some people, but never for some others, including myself. It would severy depends on hardware or firmware.

And back to hibernation, using file(s) for saving states including the whole physical memory is NOT AT ALL FOR ZFS USERS.
It would cause double-faults (page fault while in kernel mode) because of the shortage of RAM within the process. So using swap or dedicated partition with enough size would be the safe way.
 
grahamperrin said:
Relevant: yes, as described by cracauer@. Please do give as much as reasonably possible, of the 120 GB, to swap.
Click to expand...
If I recall correctly, maybe I'm on stable/11 or 12, warnings are generated on boot for larger than 64GiB of swap partition. If this still applies, it would be better splitting into 2 or more swap partitions.
 
taiwan740 said:
Just spinning up a new instance of FreeBSD 14 on a VM. The Guided UFS disk set-up using the entire disk has reserved 3.8GB out of a 120GB disk for swap.
Click to expand...

Swap files work well on UFS and are much more flexible. Personally, I wouldn't put a fixed swap partition on a device that small unless I were installing on ZFS.
 
You may miss out in other parts, too.
If someone wants a huge page, for mapping or I/O, it can be that no area for such a page is available because there is this one dirty memory page in the middle. The kernel could drop that to swap and thus clear the way, so to speak. Bit it needs some swap space for that. Usually I set up a minimum of one to five hundred MB aside for this.
There are also processes launched at boot which are not used for a long time (say, init for example). The memory of these can safely be swapped out and the physical memory can then be used as cache. For this case it would make no sense only if there was always memory free to use as cache without dropping anything. On the VM I am using for $JOB the cupsd has a resident memory footprint of 8MB. It has never been used.
 
Crivens said:
You may miss out in other parts, too.
If someone wants a huge page, for mapping or I/O, it can be that no area for such a page is available because there is this one dirty memory page in the middle. The kernel could drop that to swap and thus clear the way, so to speak. Bit it needs some swap space for that. Usually I set up a minimum of one to five hundred MB aside for this.
There are also processes launched at boot which are not used for a long time (say, init for example). The memory of these can safely be swapped out and the physical memory can then be used as cache. For this case it would make no sense only if there was always memory free to use as cache without dropping anything. On the VM I am using for $JOB the cupsd has a resident memory footprint of 8MB. It has never been used.
Click to expand...
Well, I've never seen any desktop system that I use even get close to using 16GB of RAM. The biggest memory user for me is Chromium, and I'm not a tab hoarder either, so this usually ends up being about 800MB.

Swap files or paging files in something like /tmp would make more sense to me, than reserving a partition dedicated to this, on the outside chance I might use something that somehow swallows up 16GB of RAM. Where do you draw the line with the swap? But I'd also be slightly disappointed if even in low memory usage conditions, the system was swapping RAM out to diskspace.
 
taiwan740 said:
Swap files or paging files in something like /tmp would make more sense to me
Click to expand...
if you are using tmpfs for /tmp, it SHALL be avoided.
By default, tmpfs is swap-backed, meaning "if free RAM is too small to write the file to the tmpfs (in this case, /tmp), tmpfs attempts to swap something in it, and in this case, if the file to write is larger than the free space in the swapfile plus free RAM, it should cause crash.
 
Swap is still relevant. It's useful to back dirty anonymous pages when there is memory pressure. Laundering pages gives more options. It might not happen often, but when it does you'll hit more pathological behavior.

You can run without it. But even at Netflix where we have oodles of memory we have swap space. It helps with "inrush" as we take on a lot of load. Or when we have a sudden change in load. And it's a place for our crash dumps.

So it helps... but maybe you don't care about the improvements...

Warner
 
This is 19 hours into building Chromium and dependencies from ports. Frustrating that I can't have that extra 4GB space back. On this PC (a desktop) it's not an issue because I can add another disk, but on other hardware where you are more constrained on IO and storage devices, this could be very annoying. I just think there's a better design out there (like using page files) or a folder, rather than a disk partition.

</moan>

I probably have an extremely simplied view of how it works. I will bathe in my ignorance from my code-free ivory tower.
 

Attachments

  • Screenshot 2024-01-03 at 16.15.29.png
    Screenshot 2024-01-03 at 16.15.29.png
    134.8 KB · Views: 111
You must log in or register to reply here.
Back
Top