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.