4 ms·
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
by ars 1y ago
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.
- saurik 1y agoWhy 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?
- cwillu 1y agoBecause swapping back in happens 4kb at a time
- cycomanic 1y agoWhy?
- worthless-trash 1y agoBecause of page size. Its treated like any other page.
- mnw21cam 1y agoIt'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.
- blueflow 1y agoValid argument with FAT on spinning rust, invalid with ext4 on ssd. ext4 is extent-based so the fragmentation overhead doesn't happen.
- Suzuran 1y agoThe swap partition does not have a filesystem, it is a linear list of blocks.
- deleted 1y ago[deleted]
- blueflow 1y agoNeither i nor parent said that. Confusion?
- ars 1y agoYou 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?
- deleted 1y ago[deleted]
- cwillu 1y agoext4 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.
- imp0cat 1y agoMost 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.en.html#the-temporary-files-directory-tmp-is-now-stored-in-a-tmpfs https://www.debian.org/releases/trixie/release-notes/issues....
- magicalhippo 1y agoIf 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.
- imp0cat 1y agoRight, 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.
- mhitza 1y agoWhat 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!
- mnw21cam 1y agoRight, 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.
- marginalia_nu 1y agoThis 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.
- ars 1y agoReading it back from a filesystem is much much faster than reading it back from swap.