71–80 of 256 posts
There used to be a time when not only the OS required using partitions for optimum performace (swapfiles) but also applications. In the late 90s databases were regularly set up in a way to store their data on raw partitions. There were other types of applications too that required partitions but for databases it was really common. The practice really only died with OSes allowing apps to bypass the normal filesystem c…
Earlier quoted context omitted.
I believe that you mean: https://en.wikipedia.org/wiki/Thrashing_(computer_science) Chris Siebenmann discusses when the OOM killer triggers: https://utcc.utoronto.ca/~cks/space/blog/linux/OOMKillerWhen Chris disables systemd-oomd after it obliterates his X session with no explanation: https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdOomdNo...
> First off, this is exactly how systemd-oomd is supposed to behave under memory pressure. The documentation is specific on this; systemd-oomd itself says: > > [...] If the configured limits are exceeded, systemd-oomd will select a cgroup to terminate, and send SIGKILL to all processes in it. [...] > By having the user@.service template be enrolled in systemd-oomd, Fedora made the cgroup that systemd-oomd would selec…
In my experience it works really well. I wonder why my computer is a bit sluggish, and find out I have several gigs in zram.
If that was in swap on a disk, it would be really painful.
Earlier quoted context omitted.
On Windows you can achieve something like manual overcommit by calling VirtualAlloc with just MEM_RESERVE. That gives you a continuous space in your process's virtual address space, without actually backing it with any physical pages. Kind of like what a malloc does on linux But where linux would automagically back those pages once you use them, Windows requires you to actually ask for those pages to be backed by som…
At a glance that seems like a much more sensible design. I guess it's dead in the water for posix on account of fork being CoW? This is quite the rabbit hole. I wonder if programming languages ought to be designed in such a way to accommodate a preemptive signal indicating allocation failure in place of a page fault? Rather than malloc returning null or etc.
If that's the only issue, it's avoidable for most use cases. Lots of processes that fork are doing fork/exec to run a helper program. If they know they will do that and that they will be a large process, it's often useful to setup a fork/exec helper in early application startup.
However, there are some applications that use CoW more intentionally. Lock -> fork -> (unlock in parent / persist coherent snapshot in child) is a common pattern; I believe redis uses thst pattern and I've seen it mentioned in discussions about MMO servers. I believe postgres uses fork and CoW for transaction isolation ... but postgres also runs on Windows so there must be another way or I don't understand.
For the persist case, you could imagine some sort of flag to fork to allow overcommit and maybe even to let CoW requests stall in the parent rather than fail... the child is expected to do its work and exit in a limited time.
Swap files are for "oh shit, I need to run this rare thing that needs lots of VM". You create them, "swapon", then "swapoff" and remove when done.
There used to be a time when not only the OS required using partitions for optimum performace (swapfiles) but also applications. In the late 90s databases were regularly set up in a way to store their data on raw partitions. There were other types of applications too that required partitions but for databases it was really common. The practice really only died with OSes allowing apps to bypass the normal filesystem c…
was this before mmap(2)?
O_DIRECT was resisted by Torvalds and others, but it's there today, and used by supposedly important platforms. Nvidia even has an API to DMA data to and from GPUs that uses O_DIRECT. There are folks working on new async WAL O_DIRECT for PostgreSQL as well.
So what can be said? mmap(2) isn't sufficient for certain cases. Torvalds has faced and successfully navigated difficult design choices in a pragmatic manner. What else?
The lesson I take is this: there are levels to implementation complexity and value. The wisdom to decide the appropriate abstraction level is crucial. You are unlikely to be equipped well enough to beneficially utilize O_DIRECT, but it's not impossible and some, in fact, are so equipped.
Earlier quoted context omitted.
I have FDE with keys in the TPM. It's pretty smooth bit required a one time additional step in Fedora. It's also probably not very secure, but my threat model is simple theft.
What's the benefit of using the TPM compared to a simple passphrase at boot, in that scenario?
Oh, the irony of: echo "/swapfile none swap defaults 0 0" >> /etc/fstab If we are going full modern, why not create a Systemd unit? ( https://www.freedesktop.org/software/systemd/man/latest/syst... ) if you need more info. If you didn't know this: /etc/fstab is not used directly after the pivot. Systemd parses it, creates units for every record in it, and that's what gets executed in reality. I can't imagine why woul…
[flagged]
Systemd is probably on 80%+ linux systems that people interact with, and 95%+ that people manually configure.
Swap partitions are your set-and-forget permanent installation that covers daily use. Swap files are for "oh shit, I need to run this rare thing that needs lots of VM". You create them, "swapon", then "swapoff" and remove when done.
Tangential, but does anyone know why in 2026 and on Debian 13, my machine still hangs when some process exhausts RAM? Is there really no higher-priority kernel process to prevent total freeze of the system and send a SIGKILL to the culprit process when such a scenario happens?
It's because linux is a toy OS. Specifically, it overcommits memory in the hope/assumption that it won't all be used at once, but doesn't have a way to gracefully degrade when applications collectively want to use more memory(+swap) than it actually has. You can turn off overcommit, but applications are designed with the overcommitting feature in mind, so your experience might not be as good as you were hoping for.
Making a massive swap space helps a little bit. It's better to just never let your actual memory usage go above 85% to 90%. It's fine to go above if you're trying to optimize a server with a specific set of processes to wring every last bit of efficiency out of it, but not for general desktop computing.
If it really bothers you OpenBSD (edit: thanks for the reminder TimTheTinker) and Illumos don't allow overcommit at all and Windows handles this situation much more gracefully, so WSL is an option too. If you don't mind Oracle (i do), solaris also doesn't allow overcommit.