On Fri, Aug 30, 2019 at 1:55 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > Hi, > This is yet another follow-up for this thread: > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/XUZLHJ5O32OX24LG44R7UZ2TMN6NY47N/ (Benchmarks being fraught with peril, synthetic benchmarks even more fraught with peril but at least their bias is obvious rather than obfuscated behind unknown cutsy attempts to simulate an environment no one has.) This old bash fork bomb example fails (Fedora 31, earlier versions not tested) $ :(){ :|:& };: [ 1765.728408] cgroup: fork rejected by pids controller in /user.slice/user-1000.slice/session-3.scope So use 'munch' instead https://gist.github.com/n3rve/7897c8ce1e17c22dc17a1df1b4e645f4 kernel 5.2.13 $ time ./munch Measuring the time it takes to fill all memory and swap. I'm waiting about 1 minutes between each run, with no other activity happening during that time. The typical outcome is: "Allocated 14729 MB Killed" 8GiB RAM, 8GiB swap on SSD plain partition 1. 0m43s 2. 0m47s 3. 0m46s now enable zswap, lz4/zbud, with a 20% pool 1. 0m10s 2. 0m10s 3. 0m11s now disable all of that (zswap and the swap on SSD) enable swap on ZRAM at 1:1 ratio with installed RAM, using lz4 1. 0m11s 2. 0m10s 3. 0m11s ----------- In the 2nd case, with zswap, swapon does in fact report 8GiB gets used just before the kill. That's a little confusing because zswap compresses both the memory pool as well as what spills over to the swap partition. Do I have more swap available because it's compressed? Doesn't seem to be the case as reported by 'free' or 'vmstat'. Do I use less swap on disk? swapon says no. And yet the speed it's getting to the swap partition suggests it's really completely compressed already and isn't really generating much of any writes (because it's a synthetic test, I assume all zeros, and thus highly compressible). ? So, it's vaguely interesting. Slightly more interesting, comparison to swapfiles on the same SSD, per file system. Btrfs 1. 0m50s 2. 0m46s 3. 0m53s Ext4 1. 1m18s 2. 1m2s 3. 1m6s XFS 1. 0m48s 2. 1m2s 3. 1m1s Btrfs had the disadvantage in that it was not a new file system, rather substantially used, many file system resizes. The ext4 and XFS file systems were created just for the test, and were created on partitions that had 'blkdiscard' issued beforehand. It's a requirement to use chattr +C (nodatacow) on Btrfs, which implies nocsum and nocompression. Anyway, they aren't ridiculously out of line with using a plain partition. So plausibly someone could create a systemd generator that dynamically creates and destroys swapfiles. And also creates a hibernation file just before hibernating. Not sure about encryption for any of that though. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
