On Friday, June 5, 2020 11:57:50 PM MST Samuel Sieb wrote: > On 6/5/20 11:43 PM, John M. Harris Jr wrote: > > > Completely agreed, going about it this way would also address most of my > > concerns with this change, as it would mean it's easy for people like > > myself to opt out. > > > If you don't want it, then disable the generator or uninstall it. I > don't understand why you're so against this. It's not even really new. > Is it because you don't understand it? Try it, you'll like it. It made > such a big difference on my laptop. I'm going to be activating it on my > other computers and servers as I get time. Most of the servers have > enough RAM to not need swap, but it makes a nice safety net with > virtually no overhead. On my laptop, a Lenovo X200T with Core(TM)2 Duo CPU U9300; 6 GiB RAM, enabling swap on zram led to increased CPU usage (Always above 13% where normally idling at 6%!), and my entire system freezing after about 30 minutes. In all fairness, I don't know why my system froze, as I couldn't get anything over netconsole and sysrq wasn't working, but I think I'm going to leave it disabled. Swap on disk is more than fast enough for buffer/cache and hibernation/resume on my system. I don't know why people seem to be repeating what seems to be the result of a placebo, saying that their system "feels more responsive" with swap on zram. People seem to be forgetting why swap on zram came up to begin with, it has nothing to do with system "responsiveness", which wasn't an issue. It had to do with dealing with OOM. Swap on zram isn't even a solution to that, it just changes how specifically it affects systems. For servers, swap is useful regardless of the amount of RAM. Swap is very nice for use as buffer/cache, and leaves space in RAM for whatever the server is running. For example, I always configure a 4 GiB swap partition on servers with 8-24 GiB of RAM, and 8 GiB swap for servers with 64-128 GiB, 16 GiB on servers with 128-256 GiB, etc. Beyond that, tuning is a bit different depending on the workload, but it sets a very nice starting point. -- John M. Harris, Jr. _______________________________________________ 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
