A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

File is tmpfs will swap out if your system is under memory pressure.

If that happens, reading the file back is DRAMATICALLY slower than if you had just stored the file on disk in the first place.

This change is not going to speed things up for most users, it will slow things. Instead of caching important files, you waste memory on useless temporary files. Then the system swaps it out, so you can get cache back, and then it's really slow to read back.

This change is a mistake.

Why is reading the data back from swap be slower at all -- much less "DRAMATICALLY" so -- than saving the data to disk and reading it back?

Most systems probably aren't having problems with insufficient RAM nowaday though, do they? And this will reduce wear on your SSD.

Also, you can easily disable it: https://www.debian.org/releases/trixie/release-notes/issues....

Because swapping back in happens 4kb at a time

If you're running it in a VM you might not have all that luxurious RAM.

When my Linux VM starts swapping I have to either wait an hour or more to regain control, or just hard restart the VM.

Right, but if it's a VM, it's probably provisioned by something like ansible/terraform? If so, it's quite easy to add an init script that will disable this feature and never have to worry about it again.

What distro are you running? systemd-oomd kills processes a bit quicker than what came before (a couple minutes of a slow, stuttery system). Still too slow for a server you'd want to have back online as quickly as possible.

At least now when I run out of memory it kills processes that consume the most memory. A few years back it used to kill my desktop session instead!

Why?

Because of page size. Its treated like any other page.

On small VPS systems with 512 MB or 1 GB you're more likely to notice (if /tmp is actually used by what's running on the sytem).

This doesn't really make sense. If /tmp was an on-disk directory the same memory pressure that caused swapping would just evict the file from the page cache instead, again leading to a cache miss and a dramatically slower read.

It's also because a filesystem is much more likely to have consecutive parts of a file stored consecutively on disc, whereas swap is going to just randomly scatter 4kB blocks everywhere, so you'll be dealing with random access read speed instead of throughput read speed.

Right, that's traditionally been because the X server has typically had a fairly large footprint, and therefore has been very attractive for the oom killer. But in the last 15 years or so, some heuristics have been applied to deliberately discourage the oom killer from killing "important things".

I install earlyoom on systems I admin. It prevents the low-memory thrashing by killing things while the system is still responsive, instead of when the system is in a state that means it'll take hours to recover.

Valid argument with FAT on spinning rust, invalid with ext4 on ssd. ext4 is extent-based so the fragmentation overhead doesn't happen.

The swap partition does not have a filesystem, it is a linear list of blocks.

Neither i nor parent said that. Confusion?

You wrote your comment like it was a rebuttal of the person above you, but the text supports what they said: A filesystem is faster than swap for this.

What was your intent?

Reading it back from a filesystem is much much faster than reading it back from swap.

It's not about insufficient ram, it's about reserving ram for much more important things: cache.

This changes puts the least important data in ram - temp files - while evicting much more important cache data.

ext4 is irrelevant to what happens when a file is backed by swap; even with swapfiles, the mm subsystem more or less goes behind the back of the filesystem to access the disk corresponding to the swapfile.

The overhead of making (size-of-read / 4kb) requests (potentially stalling the reading process for every page) is relevant even on an ssd; there are costs to random access beyond moving a disk head and waiting for a platter to spin into position, and those costs are still relevant with solid-state storage.