171–180 of 257 posts
Use zram instead. This from crappy 8G RAM multimedia/browsing minipc I'm on right now. The SSD is quite slow and browser is memory hungry so it was an improvement from on disk swap. $ zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 zstd 3G 482.9M 86.7M 91.8M 4 [SWAP]
Earlier quoted context omitted.
zram is a good choice when data in RAM is very repetetive/compressible. Web browsers is one such load. Android apps is another good one. When that data doesn't compress well at all, zram is no help and traditional swap-to-storage is a better choice. And there is a middle-ground option, zswap: swapped out pages will eventually end up on a block device, but are compressed first.
Zram also supports a block device for pages that do not compress. So the primary advantage of zswap is that one can use its swap for hibernation while it does not work with zram.
Earlier quoted context omitted.
On x64 CPU for laptops the memory bandwidth is rather limited and a fast compressor like lz4 can saturate it. As the result latest SSD are faster then z-ram when using hardware encryption on SSD.
If you care about performance you shouldn't be running from swap period. Swap is just a safety net.
Earlier quoted context omitted.
> 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…
One thing Fedora does now, is use zram. 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 x64 CPU for laptops the memory bandwidth is rather limited and a fast compressor like lz4 can saturate it. As the result latest SSD are faster then z-ram when using hardware encryption on SSD.
If you care about performance you shouldn't be running from swap period. Swap is just a safety net.
Here's a good summary of what it actually does. https://chrisdown.name/2018/01/02/in-defence-of-swap.html
TL;DR that swap shouldn't be seen as "spare RAM", but a mechanism for paging out anonymous pages, which is desirable in many circumstances in avoiding OOM situations and making memory management work better. It paradoxically typically reduces I/O thrashing.
Why use swap files when we could have swap directories? ;-) Sprite had (IMO) a really interesting solution to swap. Each host had a directory, referenced by its host ID under the `/swap` directory, and inside that directory, individual segments of virtual memory would be saved: https://github.com/OSPreservProject/sprite/blob/master/src/k... Sprite overcommited memory like a modern OS, and stored segments individually…
Are you running Sprite in qemu or on hardware? I ran a small Mosix cluster a couple times just for funsies. I had forgotten about Sprite as the other SSI cluster operating system. It is really too bad that this line of research trailed off.
The Sprite kernel released by UCB doesn't run on any qemu target, but I've made ports to the PC and to sun4m, which qemu can run. I've gotten the sun3 (m68k) and sun4 (sparc) ports to run in phabric's fork/continuation of TME, NME [0], but the Lance emulation has a bug that'll cause some longer Ethernet frames to have a few bytes lopped off the end (kernel panics on RPC calls!) and the m68k MMU is missing an edge case that makes init segfault right after exec(). Need to upstream those sometime...
I've been running my cluster mostly off a mini PC with an N95 Atom CPU (root server + couple hosts to login to, Sprite's local filesystem path is buggy and shouldn't be trusted), with virtio network and storage drivers ported to Sprite. Sips electricity, and plenty fast storage for everything else. Migration works great between a real 486 PC compatible and my Zen5 desktop, along with some real SPARCstations mixed in there, and a SPARC laptop for fun.
I wanna release it some day, it'd be super easy to deploy new clusters with a single qcow2 and maybe a libvirt XML domain, but the code is currently a mess and still missing stuff, like a working `addhost` command (the provided one is just a csh script which checked files in/out of an RCS repo in /etc, with hardcoded paths to host mounts at Berkeley...)
[flagged]
Also, this seems to be based on a email from 2005, about kernel version 2.4 and 2.6, and their differences. Things might have changed since then, and also depends on a lot of factors, not the least what filesystem you use. I'm not sure people should seriously follow advice that basically boils down to "do this always it's best". Better instead to make yourself informed about the tradeoffs, then make your own choice,…
> fallocate / chmod / mkswap Why not "mkswap --size ... --file ...", which does these three things and more? For instance, according to the mkswap man page, "[...] sets the nocow attribute for newly created files [...]" which is a detail that seems to be missing from this gist.
Also, fallocate+chmod is racy: between the two calls, an attacker could open the file, and then keep it open until next reboot. OTOH, mkswap creates the swap file with the correct permissions straight away. The --size and --file options are relatively new, though: they were added in util-linux v2.40, released in 2024.
I feel like if there's a malicious user (or program) on your system with the necessary access for this, you have much bigger problems.